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ABSTRACT 



A technique for implementing in a networked client-server 
environment, e.g., the Internet, network-distributed adver- 
tising in which advertisements are downloaded, from an 
advertising server to a browser executing at a client 
computer, in a manner transparent to a user situated at the 
browser, and subsequently displayed, by that browser on an 
interstitial basis, in response to a click-stream generated by 
the user to move from one web page to the next. Specifically, 
an HTML advertising tag is embedded into a referring web 
page. This tag contains two components. One component 
effectively downloads, from a distribution web server and to 
an extent necessary, and then persistently instantiates an 
agent at the client browser. The other component is a 
reference, in terms of a web address, of the advertising 
management system. The ad management system selects the 
given advertisement that is to be downloaded, rather than 
having that selection or its content being embedded in the 
web content page. 
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# Section 1 ■ Applet Player Java Class Configuration 
playerName=AppletViewerPopup 

playerClass=com.unicast.adcontroller.players.AppletViewerPopup 

# Section 2 ■ Ad Java Classes Configuration 
AppletViewerPopup.adAppletName=ANM_AnimationLoaderApplet 
AppletViewerPopup.adAppletClass= 

com.pointcast.applets.AnimationApplet.ANM_AnimationLoaderApplet 

# Section 3 - Player Execution Configuration 
AppletViewerPopup.windowTitle=AdController PointCast Ad 
AppletViewerPopup.playerRefreshRate=1000 
AppletViewerPopup.allowExit=true 
AppletViewerPopup.xPosition=50 
AppletViewerPopup.yPosition=50 
AppletViewerPopup.windowWidth=280 
AppletViewerPopup.windowHeight=355 
AppletViewerPopup.isResizable=false 
AppletViewerPopup.secondsWindowlsOpen= 1 80 
AppletViewerPopup.secondsToOverlay=1 
AppletViewerPopup.closeButtonLabel=Close 
AppletViewerPopup.openButtonLabel=Morelnfo 
AppletViewerPopup.saveButtonLabel=Save 
AppletViewerPopup.openURL=http://www.pointcast.com/ 

# Section 4 - Ad Applet Configuration 

# A. Ad Applet DocumentBase 

AppletViewerPopup.ANM_AnimationLoaderApplet.documentBase= 
http^/wvvw2.unicastxom/-rlandsma/AdController/MacromediaApplet/ 

# B. Ad Applet Parameters 

AppletViewerPopup.ANM_AnimationLoaderApplet.AdToPlay=deepsea.anm 

AppletViewerPopup.ANM_AnimationLoaderApplet.Altlmage=test.gif 

AppletViewerPopup.ANM_AnimationLoaderApplet.MaxCycles=5 

AppletViewerPopup.ANMJVnimationLoaderAppto^ 

AppletViewerPopup.ANM_AnimationLoaderApplet.TargetFrame=_top 

AppletViewerPopup.ANM_AnimationLoaderApplet.BorderWidth=2 

AppletViewerPopup.ANM_AnimationLoaderApplet.BorderType=Standard 

# C. Ad Applet MediaList 

AppletViewerPopup.ANM_AnimationLoaderApplet.mediaURLList=new 
AppletViewerPopup.ANM_AnimationLoaderApplet.mediaURLList.size==2 
AppletViewerPopup.ANM„AnimationLoaderApplet.mediaURLList.elementO=deepsea.anm 
AppletViewerPopup.ANM_AnimationLoaderApplet.mediaURLList.elementO=animAppl^ 



/ 



2000 



FIG. 20 
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AD CONTROLLER FOR USE IN 
IMPLEMENTING USER-TRANSPARENT 
NETWORK-DISTRIBUTED ADVERTISING 
AND FOR CVTERSTITIALLY DISPLAYING 
AN ADVERTISEMENT SO DISTRIBUTED 5 

CROSS-REFERENCE TO RELATED 
APPLICATION 

This application is a divisional of our United States patent 
application entitled "A TECHNIQUE FOR IMPLEMENT- 30 
ING BROWSER-INITIATED USER-TRANSPARENT 
NETWORK-DISTRIBUTED ADVERTISING AND FOR 
INTERSTITI ALLY DISPLAYING AN 
ADVERTISEMENT, SO DISTRIBUTED, THROUGH A 
WEB BROWSER IN RESPONSE TO A USER CLICK- 15 
STREAM" filed Jan. 26, 1999 and assigned Ser. No. 09/237, 
718 which is a continuation-in-part of our United States 
patent application entitled "LOCALLY-SUMMONED 
NETWORK-DISTRIBUTED CONFIRMED INFORMA- 
TION PRESENTATIONS", filed May 15, 1998 and 20 
assigned Ser. No. 09/080,165 (now abandoned) which is 
incorporated by reference herein. 

BACKGROUND OF THE DISCLOSURE 

1. Field of the Invention 25 
The invention relates to a technique, specifically appara- 
tus and accompanying methods, for implementing in a 
networked client-server environment, such as the Internet, 
network-distributed advertising in which an advertisement is 3Q 
downloaded, from an advertising server to a web browser 
executing at a client computer, in a manner transparent to a 
user situated at the browser, and subsequently displayed, by 
that browser and on an interstitial basis, in response to a 
click-stream generated by the user to move from one web 35 
page to the next. 

2. Description of the Prior Art 

Currently, Internet usage, and particularly that of the 
World Wide Web (henceforth referred to as simply the 
"web"), is growing explosively, particularly as the number 40 
of web sites and users that have access to the Internet 
continue to rapidly and to a great extent, exponentially, 
expand. 

In essence, after establishing a suitable network connec- 
tion to the Internet, a user at a client computer can easily 45 
employ a graphical web browser, such as the Internet 
Explorer ("IE") browser presently available from Microsoft 
Corporation of Redmond, Wash., to connect to a web site 
and then download a desired web page by simply supplying 
a specific address (known as a URL or uniform resource 50 
locator) of that page to the browser. The URL identifies both 
an address of the site, in terms of its Internet domain name, 
and a page of information at that site, in terms of its 
corresponding file name. Each web site stores at least one, 
and often times substantially more pages all arranged in a 55 
pre-defined hierarchy, generally beginning, at its root, with 
a so-called "home page". Each such page is written in 
HTML (hypertext markup language) form. A page, in this 
context, refers to content accessed via a single URL, 
including, e.g., text, graphics and other information speci- 60 
fied in HTML code for that particular page. Once a user 
supplies a URL of interest, the browser operated by that user 
sends an appropriate command, using a TCP/IP protocol 
(transmission control protocol/internet protocol), to a remote 
HTTP (hypertext transport protocol) server, located at the 65 
web site and which stores that page, to access and download 
a corresponding file for that page. In response, the server 
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then sends, using the TCP/IP protocol, a stored file contain- 
ing HTML code that constitutes that page back to the 
browser. As the file that constitutes the page itself is received 
by the browser, the browser interprets and executes the 
HTML code in that file to properly assemble and render the 
page on, e.g., a monitor to a user situated at the client 
computer. Such a page may itself contain HTML commands 
that reference other files, residing on the same or different 
web sites, which, when these commands are appropriately 
interpreted and executed by the browser, result in those files 
being downloaded and their resulting content properly 
assembled by the browser into the rendered page. Once all 
the content associated with the page is rendered, the user can 
then position his(her) mouse cursor on a suitable hypertext 
link, button or other suitable user input field (whichever here 
implements a "hotlink") displayed on that page and then, 
through, e.g., a mouse "click", effectively download a file 
for and render another desired page in succession until the 
user has finished his(her) visit to that site, at which point, the 
user can transition through a hotlink to a page at another site, 
and so forth. A hotlink specifies a complete web address of 
an associated page, including a domain name of its hosting 
web site at which that page is situated. Consequently, by 
simply and successively positioning and "clicking" his(her) 
mouse at an appropriate hotlink for each one of a number of 
desired web pages, the user can readily retrieve an HTML 
file for each desired page in succession from its correspond- 
ing web site and render that page, and, by doing so, 
essentially effortlessly jump from site to site, regardless of 
where those sites are physically located. 

Ever since their introduction several years ago, HTML 
and accompanying browser software, now including, e.g., 
attendant programming languages such as Java and JavaS- 
cript languages ("Java" is a registered trademark of Sun 
Microsystems in Mountain View, Calif.; "JavaScript" is a 
trademark of Netscape Communications in Mountain View, 
Calif.), have undergone rather rapid and continual evolution. 
A major purpose of which has been and continues to be to 
provide web page authors with an ability to render increas- 
ingly rich content through their pages and, as a result, 
heighten a "user experience" for those users who visit these 
pages. Consequently, web pages are no longer limited to 
relatively simple textual displays — as occurred with early 
versions of HTML and . browser software, but can now 
encompass even full-motion multimedia presentations and 
interactive games that use rather sophisticated graphics. 

The simplicity of browsing the web coupled with the 
relative low-cost of accessing the Internet, and the relative 
ease through which a web site can be established are 
collectively fueling unparalleled growth and diffusion of the 
Internet itself, web sites and the Internet user community 
throughout the world. In that regard, by establishing web 
sites, merchants, vendors and other information providers 
have an unparalleled opportunity, basically unheard of as 
little as 5-10 years ago, to reach enormous numbers of 
potential consumers — regardless of where these consumers 
reside — at costs far less than previously thought possible. 
Moreover, given the staggering amount and wide diversity 
of information currently available on the web, web browsing 
is becoming so popular a past-time for sufficient numbers of 
individuals that browsing is beginning to divert significant 
viewership away from traditional forms of mass 
entertainment, such as television and cable. While such 
diversion is relatively small at present, it is likely to rapidly 
grow. Moreover, given the ease and convenience with which 
users, situated at their personal computers and with basically 
nothing more complicated than a few mouse clicks, can 
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effectively interact with remote web sites, electronic render the page, including the banner, after a user transi- 

commerce, through which goods and services are ordered tioned to that page. Channel bandwidth to a client computer 

through the Internet without ever visiting a physical store, is (e.g., personal computer — PC), such as that provided 

rapidly emerging as a significant sales medium. This through a modem connection, is often rather limited, 

medium is likely to significantly challenge and possibly, 5 Consequently, if the file size for the banner were relatively 

over a relatively short time, may even alter traditional forms large— as would certainly be the case for relatively "rich" 

of retailing content, e.g., audio or video content, the delay in download- 

• , - . ing such a file over such a limited bandwidth connection 

Given the wide and ever-growing reach of the web as a ^ be exccssive> and CODSeqU ently highly frustrating to 

source of consumer information and the increasing con- me ^ HencCj a user would Ukd wait a considerable 

sinner acceptance of electronic commerce, advertisers have io ^ om{ Qf ^ before aU ^ components for multi- 

clearly recognized the immense potential of the web as an m ^ CQn{tn[ ^ fuU downloaded l0 it lhat t0 be 

effective medium for disseminating advertsements to a rendered Such dcUy> if encountered during a page 

consuming public. transition, can be rather frustrating to a user, even to the 

Unfortunately, conventional web-based advertising, for point at which the user, just to end his(her) waiting, will 

various practical reasons— some being technical in nature prematurely terminate the download and transition to 

and others relating to a nature of traditional web advertise- another page. Therefore, in an effort to preserve an appro - 

ments themselves, has generally yielded unsatisfactory pri ate "editorial experience" for a user, content suppliers 

results and thus has usually been shunned by most large sh arply limit the file size, of such banners to be rendered on 

advertisers. In that regard, several approaches exist in the art t h e ir pages, in order to minimize page download and hence 

for implementing web based advertisements. However, all latency times. 

suffer serious limitations of one form or another that have Unfortunately, such restricted file sizes effectively limit 

sharply restricted their desirability and use. the rich ness of the content of a banner to a rather simplistic 

Currently, a predominant format, referred to as a advertisement — even with animation. Thus, banners often 

"banner", for a web advertisement takes the form of a 25 failed, as advertisers soon recognized by relatively low 

rectangular graphical display situated, typically at a fixed click-through counts, to attract sufficient viewer attention to 

location, in a rendered web page. A banner, which can be justify their use and expense. 

static or animated, can be situated anywhere within a ren- j n aa effort to overcome the content limitation associated 

dered web page but most often is situated at a top or bottom, ^th banners, the art teaches the use of a different advertising 

or along a vertical edge of that page. A banner, depending on 3Q mo dality: so-called "interstitial" advertisements. See, e.g., 

its size, can extend across an entire page width or length, and U.S. Pat. No. 5,305,195 (issued to A. J. Murphy on Apr. 19, 

usually contains, in a graphical eye-catching form, a name of 1994 — hereinafter the "Murphy" patent) which discloses the 

a product or service being advertised. Increasingly, a banner concept of using interstitial advertisements though not in the 

for a given product or service implements a hotlink to enable context of web advertising. As described in the Murphy 

a consumer to "click-through" the banner (i.e., generate a 35 patent, pre-stored advertisements are displayed at specific 

mouse click on the banner) in order to transition, via his intervals on each one of a group of networked ATM 

browser, to a web site maintained by a corresponding (automated transaction machines) terminals. In particular, 

advertiser and, from that site, fetch a web page to provide tne advertisements are downloaded, either directly or via a 

additional information regarding that product or service. server, from a remote computer and locally stored on each 

Hence, the consumer could easily obtain more information 4Q sucn terminal and subsequently displayed on that terminal 

by a click-through; while an advertiser, monitoring counts of wn j| e i t wa its for a response, from a remote mainframe 

such click-throughs that occur in a given period of time, transaction server, to a transaction initiated at that terminal 

could gain feedback on the effectiveness of the correspond- Generally speaking and with specific reference to web 

ing banner. advertising, interstitial ads are displayed in an interval of 

A banner is generally produced by properly embedding 45 time that occurs after a user has clicked on a hot-link 

specific HTML code for that banner within the HTML displayed by a browser to retrieve a desired web page but 

coding for a given web page in which the banner is to appear. before that browser has started rendering that page. Such an 

A client browser, as it interprets and sequentially executes interval, commonly referred to as an "interstitial", arises for 

the HTML code for a fetched page, will, in turn, compile and the simple reason that a browser requires time, once a user 

execute the embedded code for the banner and hence display 50 clicks on a hotlink for a new page, to fetch a file(s) from a 

the banner, as part of a rendered page and at a specified remote web servers) for that particular page and then fully 

location thereon. assemble and render that page. The length of an interstitial 

In implementing a banner, whether static or even interval, which is quite variable, is governed by a variety of 

animated, its HTML coding generally involved download- factors, including, e.g., a number of files required to fully 

ing an appropriate file, for that banner, to a client browser. 55 render the new page and the size of each such file, and 

The file may be stored on the same server that stores the network and server congestion and attendant delays occur- 

HTML file for the page, or accessed from a remote server. ring when the user activated the hotlink. 

The file may contain a graphic itself, such as in a GIF Interstitial web advertising is taught in, e.g., U.S. Pat. 

(graphic interchange format) file, or a Java applet which, Nos. 5,737,619 and 5,572,643 (both of which issued to D. H. 

once interpreted and executed by the browser, generates and 60 Judson but on Apr. 7, 1998 and Nov. 5, 1996, respectively — 

renders a desired animated graphic. This file, whether it be hereinafter the "Judson" patents). The Judson patents dis- 

a graphic or applet, requires time to download and must be close the concept of embedding an advertisement, as an 

downloaded and assembled by the browser on the page prior information object, in a web page file in such a manner that 

to that page being fully rendered. The download time for that the object will remain hidden and not displayed when the file 

file, particularly as it increases in size, clearly, a priori, 65 is executed to render the page. Rather than being displayed, 

lengthens a time interval during which that page would the information object is locally cached by the browser 

completely download, thereby extending the time to fully during execution of the code for that page. Then, during a 
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transition initiated by user activation of a hotlink to move 
from that page to a next successive page, i.e., during an 
interstitial, the browser accesses the advertisement from 
local cache and displays it until such time as that next 
successive page is downloaded and rendered. See also, 5 
published International patent application WO 97/07656 (to 
E. Barkat et al and published on Mar. 6, 1997) which teaches 
the concept of "polite" downloading. Here, a browser, on a 
local computer (e.g., a client PC) downloads, from a remote 
advertising system server and ostensibly as a background jq 
process, file(s) for a web advertisement only during those 
intervals when bandwidth utilization of a communication 
channel (link) connected to the browser is less than a 
pre-established threshold. Such "polite" downloading is 
intended to minimally interfere with other communication 15 
applications, then executing on the client PC, which will 
utilize the link. The browser displays the downloaded ad(s) 
to the user only after the user has not interacted, as detected 
by a conventional screen saver process, with his(her) PC for 
a predefined period of time, such as by neither moving a 2 o 
mouse nor depressing a key on a keyboard during that 
period. The server selects those advertisements for down- 
load to the client PC based on a user-ID and preference 
information of the user, who is then situated at that PC, and 
configuration information of that PC, which, when a con- 2 s 
nection is established between the client PC and the server, 
the client PC uploads to the server. Though the files asso- 
ciated with an interstitial advertisement can be large, these 
files are advantageously fetched by a client browser during 
those intervals when otherwise the browser would be idle 30 
and hence bandwidth utilization of its network connection 
would be relatively low. Such "idle times" would occur, in 
the absence of processing an interstitial ad, after the browser 
has fully rendered a web page and a user is viewing the page 
but has not yet clicked on a hotlink to transition to another 35 
page. During such an idle time, the browser would simply 
wait for further user input. 

By reducing, if not eliminating, problems, inherent in 
banners and engendered by download latency, interstitial 
web advertisements, by employing idle time downloading 40 
and local caching, provide a theoretical promise of convey- 
ing very rich media content with a pleasing "user experi- 
ence". However, interstitial advertisements, as convention- 
ally implemented, have serious practical deficiencies which 
have severely limited their use. 45 

Conventional interstitial, as well as other forms of current, 
web advertisements — here not unlike banners — rely on 
embedding HTML ad code, as, e.g., a separate non- 
display able object, within HTML coding for a web page. 
Unfortunately, this approach, inherent in that taught by the 50 
Judson patents, can be inflexible and expensive for an 
advertiser to implement and particularly later should that 
advertiser, for whatever reason, seek to modify his(her) ad 
content. In particular and presently, ad coding is manually 
inserted into each and every content web page that is to carry 55 
advertising. Consequently, insertion of increasingly sophis- 
ticated embedded advertising, such as multi-media or video 
or audio, in existing web site content requires a large 
investment in terms of human resources, time and cost as 
web sites, particularly large sites, increase a number of 60 
content pages available for advertising. In that regard, where 
a banner usually required insertion of, e.g., a single line of 
HTML code, content rich advertisements, such as those now 
implemented by parameterized embedded Java advertising 
applets, often consist of an entire page of coding and hence 65 
require far more extensive and increasingly labor-intensive 
and costly insertions. Moreover, over time, advertisers do 
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change their ads — such as by replacing one ad with a totally 
new version. However, once HTML ad coding is embedded 
within a number of web pages, it can be quite impractical 
and rather costly for an advertiser to access each and every 
page in which his(her) ad coding has been inserted and then 
manually change the ad coding, as desired. The impracti- 
cality and attendant cost compound if these pages are copied 
to other web sites and hence diffuse through the Internet. 

Given these deficiencies, the art teaches a concept of 
implementing web advertising through using so-called 
"push" technology. See, e.g., U.S. Pat. No. 5,740,549 (issued 
to J. P. Reilly et al on Apr. 14, 1998— hereinafter the "Reilly 
et al" patent). In essence and as described in the Reilly et al 
patent, a client PC, through execution of a "push" applica- 
tion program (called "administration manager"), establishes 
a network connection with an information server, i.e., a 
"push" web server, typically during off-hours, such as in the 
late evening or early morning, or at a predefined interval 
(e.g., every four hours). The information server then 
downloads, i.e., "pushes", to the administration manager, 
content files, such as for advertisements and/or other pre- 
defined information, that are to be played to the user 
sometime later. The administration manager, i.e., the "push" 
application, in turn, stores all the "pushed" content files into 
a local database (referred to as the "information database") 
on a local hard disk and, in response to instructions received 
from the information server, deletes those previously 
"pushed" content files which have already been displayed. 
The administration manager also maintains a user profile, 
which specifies user preferences as to the specific advertis- 
ing and/or other information (s)he wants to receive, in the 
information database. As such, through each connection, the 
information server, by selecting content from its database 
relative to preferences specified in the user profile, attempts 
to "push" fresh content to the client PC that is likely to be 
of interest to the user but without duplicating that which was 
already displayed. Stored "pushed" content is later 
displayed, using a data viewer, either on user demand or 
during those times when the user is not interacting with the 
system, here too detected by a conventional screen saver 
procedure. 

While push technology reduces download latency, by 
shifting downloads to occur at off-hours, this technology 
also suffers serious drawbacks which have greatly restricted 
its practical acceptance. 

In particular, to access "pushed" content, a user must 
initially download and install to his(her) client PC a 
separate, platform -specific, software application program, as 
well as subsequent updates to that program as new push 
capabilities are released by the manufacturer of the program. 
Unfortunately, these application programs can often extend 
to tens of megabytes in length. Since typical Internet users 
establish modem connections to their Internet service 
providers, these users will find that downloading these 
relatively large program files, even in compressed form, will 
consume an inordinate amount of time and is generally 
impractical while (s)he is actively using his(her) client PC. 
Consequently, these users arc constrained to purchasing, at 
some cost, an off-the-shelf version of the application pro- 
gram or downloading that program, typically at no cost for 
the program itself, at off-hours, when network congestion is 
relatively light. Furthermore, while some efforts are under- 
way in the art to automatically "push" and install incremen- 
tal software updates to a client PC, thus eliminating a need 
for a user to manually do so, the user still faces the burden 
associated with the initial download and installation of the 
"push" application program. 
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In addition, "push" application programs continue to as a "user impression" at a web server at an instant an 

increase in size, often considerably, as they provide added advertising file(s), e.g., a streamed file, is served, rather than 

capabilities to a user. Downloading and then regularly after the browser has completely rendered the advertisement 

updating a push application will reduce, sometimes to the user. Unfortunately, serving these ad files does not 

considerably, the amount of disk space available to the user 5 guarantee that these files will be ultimately and completely 

on his(her) client PC. Furthermore, "push" applications rely rendered by a client browser to a user. Consequently, web 

on periodically "pushing" large quantities of media content ^Tvcr generated "user impression" counts can be grossly- 

from a push server to the client PC and storing that content over . or un der-stated. For example, if a user navigates to a 

on the hard disk of that PC pending subsequent display This new conteQt after an adve rtisement has started playing 

content, depending on its volume can consume inordinate JQ bm before that advertisement completes and, by doing so, 

amounts of hard disk space. Furthermore ^advertisers have aturel terminated the advertisement, a full impression 

discovered, not surprisingly, that relatively few PC users . \ , , , t f 

.„ , /, \r .• *• u u i ii is nevertheless logged — erroneously — since that advertise - 

will undertake any affirmative action, such as by download- 4 , A ,/.^ . . . r 

i • , ii- i- „• i . i ment was completely served. Additional errors arise if a 

ing and installing an application program—almost regard- T", 7.' , . ' t " 

1 r •„ t • j * 1 • proxy server is situated between multiple client PCs situated 

less of its size, to receive advertisements and other such ■ . . , , rt Akn , , 

information 15 on an intranet or a l° ca * area networ k (LAN) and a web 

^ . * . . , , , _ . advertisement server situated on the Internet (or other inse- 

Faced wnh these practical, and rather acute, deficiencies cufe b|ic network) , n ^ a , from one of the 

inhering n web advertising conventionally provided on cliem pQ . fof me advertisemenl files will te routed t0 lhe 

either an mterstitial or push basis, web advertisers have which fa wju ^ ^ ( onward 

apparently relegated their efforts to displaying their adver- 20 , 0 ^ advertisement web ^ latt in se t0 the 

usements on a banner-like approach, through > real-tune wil) ^ Qne lete of the advertisement 

downloading and rendering of advertising HTML files. files , 0 lQe ^ resultin fetched advertisement 

Here, the advertising files are sited on remote web servers, files wil , be , ocal , cached ^ ^ servef and from 

rather than being embedded within given web page HTML , h ided tQ , he tin client PC should of the 

files, with appropriate HTML tags, which reference the ad „ ii- t Drv ™, loc . t iU„ „ -n 

, . ,.1,. . . n, . . 25 other client PCs request the same riles, the proxy server will 

files, being embedded into the web page files themselves. A #u \ . ,, . , ♦ ♦ *u u 

„ ' & . j . . 1 . , provide these files, totally unbeknownst to the web server, 

Such a tag specifies when and where, within the page, an £ + * , . »u *u j- * c *u * 

, . & v . from its local cache rather than directing a request from that 

advertisement is to appear. other pc back {Q ^ web servef H&nQ ^ me web seryer ^ 

To surmount the latency problems inherent in such be totally obUvious to each additional instance in which the 

banner-like advertisements, various proprietary media for- 3Q proxy accessed the ad files from its local cache and 

mats have appeared m the art. These formats employ disseminated the advertisement to any client PC other than 

increasingly sophisticated data compression, sometimes in that which first requested the ad . i nasmuch as some intranets 

conjunction with video and/or audio streaming. Rather than situated behind a proxy can be ralher extens i ve 

waiting for a media file to fully download prior to its being ^ tens or hundreds of thousands of individual client PCs, 

rendered, streaming permits content in a "streamed" media 35 server-based user impression accounting based on copies 

file to be presented in real-time to the user as that content de ii V ered by a web server may, owing to the presence of 

arrives at higher) client browser. While this approach proxy be inordinately low and result in significant 

clearly provides enhanced richness in content over that under . charg es to the advertiser. As of yet, no solution 

obtainable through a conventional banner and thus can apparently exists in the art that can provide accurate counts 

heighten a "user experience", it nevertheless relies, to its 40 of " user i mpre ssions" of web advertisements, 

detriment, on a continuous real-time network connection Qther conventional approaches aimed at reducing latency 

existing to a remote web server. times assoc[aie6 with downloading content files through 

Unfortunately, any network or server congestion which relatively slow speed communication links, e.g., modem 

stops the download, even if temporary, can suspend, i.e., conne ctions, have involved development and use of new 

freeze, or totally halt the "streamed" media presentation to 45 fecililics wi th i n various programming languages. These 

the user prior to Us completion. Tins interruption, if notice- approaches, most notably involving the Java and JavaScript 

able and sufficiently long, will likely frustrate the user and programming languages, while helpful, still cause inefficient 

degrade the "user experience". use of avai i able link bandwidth and still constrain the size of 

In spite of these drawbacks, particularly with respect to the content files. These limitations arise from premature 

interstitial advertisements and push technology, and appar- 50 terminations of preloaded files whenever a user transitions to 

ently for lack of a better alternative, most web advertising a new web page . Specifically, with these approaches, if a 

currently in use employs real-time streaming of graphic files user activates a hotlink to transition to a new web page while 

with their content being rendered by the browser. an a d file is being downloaded but before the downloading 

Web advertisements, like other forms of mass advertising, has completed, then the downloading simply stops. The 

do generate revenue, often in the form of an on-going stream 55 downloading will need to be re-started, but from the begin- 

of payments to the host of the ads, in this case web site ning of the file, the next time that particular ad file is 

owners. Accurate user accounting is essential to ensure that requested. Hence, the time and bandwidth that has then been 

an advertiser is not over- or under-charged given an extent expended in downloading part of that ad file is completely 

to which an ad is actually disseminated. Hence, these wasted. In practice, many users tend to quickly navigate 

payments are often tied to a function of the number of web 60 through a series of web pages until they reach a desired 

users whom the ad reached. But with web advertisements, destination. Consequently, advertisers are constrained to 

accurately ascertaining that number has been difficult and again minimize content file sizes and hence "richness" of 

problematic at best, and, given a basic technique employed their advertisements in an effort to decrease a number of 

to do so, manifestly error-prone, thereby causing unreliable premature terminations per unit time and in doing so reduce 

user counts and erroneous ad charges. 65 latency caused by downloading duplicate sections of the 

In particular and as conventionally employed, delivery of same ad file. Therefore, these approaches have generally 

a web advertisement, such as, e.g., a streamed ad, is logged proven to be wholly unsatisfactory. 
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In view of the fundamental drawbacks associated with 
various web based advertising techniques known in the art, 
interstitial web advertising appears to hold the most promise 
of all these techniques. Yet, the limitations inherent in 
conventional implementations of interstitial advertising 5 
have effectively prevented this form of web advertising from 
effectively fulfilling its promise. Moreover, the deficiencies 
inherent in all known web advertising techniques have, to a 
significant extent, collectively inhibited the use of web 
advertising in general. 10 

Thus, a pressing need exists in the art for a new web-based 
interstitial advertising technique which does not suffer from 
infirmities associated with such interstitial advertising tech- 
niques known in the art. 

In that regard, this new technique should preferably not 35 
embed advertising HTML files within a web page. If this 
could be accomplished, then advantageously such a tech- 
nique would likely provide considerable economies to 
advertisers in saved labor, time and cost in terms of both 
inserting advertisements into web page files, and later 20 
changing any of those advertisements. In addition, such a 
new technique should preferably function in a manner that 
is substantially, if not totally, transparent to a user and which 
neither inconveniences nor burdens that user. In particular, 
this new technique should preferably not require a user to 25 
download and install on his(her) PC a separate application 
program, let alone any update to it, specifically to receive 
web advertising, or perform any affirmative act, other than 
normal web browsing, to receive such advertising. 
Furthermore, this new technique should preferably be plat- 30 
form independent and, by doing so, operate with substan- 
tially any web browser on substantially any PC. Also, this 
new technique, when in use, should preferably not consume 
excessive hard disk space on a client PC. Moreover, to 
provide a pleasing "user experience", this new technique 35 
should render an ad fully and without any interruptions that 
might otherwise result from network and/or server conges- 
tion. Lastly, this new technique should provide proper 
accounting to an advertiser by accurately and validly ascer- 
taining user impressions of fully rendered advertisements. 40 

We believe that if such a new web-based interstitial 
advertising technique could be provided, then this technique, 
which should be both effective and desirable, may well 
achieve broad support and use by advertisers and acceptance 45 
by web users; hence, substantially expanding the use of 
web-based advertising in general. 

SUMMARY OF THE INVENTION 

Advantageously, our present inventive technique satisfies 50 
this need by overcoming the deficiencies associated with 
conventional web-based interstitial advertising techniques. 

Our present invention accomplishes this, in accordance 
with our broad inventive teachings, by: completely "decou- 
pling" advertising content from a web content page (also 55 
hereinafter referred to as a "referring" page); "politely" 
downloading advertising files, through a browser executing 
at a client computer, into browser caches (e.g., browser disk 
and RAM cache) at that computer and in a manner that is 
transparent to a user situated at the browser; and interstitially 60 
displaying advertisements through the browser in response 
to a user click-stream associated with normal user naviga- 
tion across different web pages. 

Specifically, our technique relies on embedding an HTML 
tag (which, where necessary, to distinguish this tag from 65 
other HTML tags, will also be referred to hereinafter as an 
"advertising tag") into a referring page. This tag contains 
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two components. One component effectively downloads, 
from a distribution HTTP (web) server and to an extent 
necessary, and then persistently instantiates an agent, imple- 
mented as a "light-weight" Java applet, at the client browser. 
This agent then "politely" and transparently downloads 
advertising files (media and, where necessary, player files), 
originating from an ad management system residing on a 
third-party advertising HTTP (web) server, for a given 
advertisement into browser disk cache (also in the case of 
media files into the browser RAM cache) and subsequently 
plays those media files through the browser on an interstitial 
basis and in response to a user click-stream. The other 
component is a reference, in terms of a web address, of the 
advertising management system from which the advertising 
files are to be downloaded. This latter reference totally 
"decouples" advertising content from a web page such that 
a web page, rather than embedding actual advertising con- 
tent within the page itself — as conventionally occurs, merely 
includes an advertising tag that refers, via a URL, to a 
specific ad management system rather than to a particular 
advertisement or its content. The ad management system 
selects the given advertisement that is to be downloaded, 
rather than having that selection or its content being embed- 
ded in the web content page. 

Advantageously, the agent operates independently, in the 
client browser, of the content in any referring web page. 
Once loaded and started, the agent executes in parallel, with 
standard browser functionality, continually and transpar- 
ently requesting and downloading advertisements to 
browser cache residing io a client computer (e.g., personal 
computer — PC) and interstitially playing those advertise- 
ments. 

In particular, once the agent is started, the agent politely 
and transparently downloads, through the client browser and 
to the browser cache, both media and player files, originat- 
ing from the advertisement management server, for an 
advertisement that are needed to fully play content in that 
advertisement. The agent also monitors a click-stream gen- 
erated by a user who then operates the browser. In response 
to a user-initiated action, e.g., a mouse click, which instructs 
the client browser to transition to a next successive content 
web page and which signifies a start of an interstitial 
interval, the agent, if all the media and player files are then 
resident on the client hard disk, plays the media files, 
through the browser and during that interstitial interval, 
directly from the browser cache. Advertisements are inter- 
stitially played typically in the order in which they were 
downloaded to the client browser. Interstitial play from 
browser cache advantageously permits previously cached 
content rich advertisements to be played through the 
browser without adversely affecting communication link 
bandwidth then available to the client browser. Thus, the full 
available link bandwidth can be used, while an advertise- 
ment is being played, to download a next successive content 
web page. 

Employing a user click-stream to trigger play of cached 
advertisements frees the user, for receiving advertising, of 
any need either to undertake any affirmative action, other 
than normal web browsing, or to learn any new procedure; 
thus, advantageously imposing no added burden on the user. 

Advantageously, the agent "politely" downloads adver- 
tisement media and player files, originating from the adver- 
tising server, to the browser cache, during what otherwise 
would be browser idle times, i.e., while a web page is being 
displayed to a user and the browser is waiting for user input. 
Caching advertisement files in this fashion advantageously 
circumvents variable latency and erratic (e.g., intermittent or 
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suspended) play that frequently occurs with conventional 
streamed and static media delivered over the web. 

At the start of an interstitial interval, the agent determines 
whether all the media and player files required to play a 
given advertisement (typically that having its so-called 5 
AdDescriptor file situated in a head of a play queue) then 
reside on the disk of the client PC or, with respect to media 
files, are resident in browser RAM cache. If so, the agent 
then accesses these files from the disk to "play" that adver- 
tisement. Since all the media and player files are then locally 10 
resident, the advertisement, from a user's perspective, is 
immediately rendered from the client hard disk or browser 
RAM cache with essentially no downloading delay, thus 
providing a highly pleasing "user experience" with rich 
multi-media content approaching that obtainable through 15 
current CD-ROM based delivery. Thereafter, the agent 
returns control to the browser to permit the browser, if a next 
successive web page has been downloaded, assembled and 
ready to be rendered, to render that particular page to the 
user. If, however, an advertisement is prematurely termi- 2 q 
nated by a user, that advertisement (in terms of its AdDe- 
scriptor file) will remain in a play queue (with its media and 
player files remaining on the client hard disk or, in the case 
of media files, in browser RAM cache) and will be re-played 
from its beginning at the start of a next successive interstitial 25 
interval. Furthermore, if download of the media and player 
files for an advertisement were to be interrupted by a user 
click-stream, i.e., start of interstitial interval, the agent 
suspends further downloading until after the ensuing inter- 
stitial interval terminates. To conserve communication link 30 
bandwidth, the agent then resumes downloading of these 
files at a point it was suspended, rather than, as convention- 
ally occurs, totally re-starting the download. 

In accordance with our specific inventive teachings, the 
agent contains two applets: a Transition Sensor applet and an 35 
"AdController" applet. Only the Transition Sensor applet is 
itself associated with any content page. Though the AdCon- 
troller applet, once started, executes under the browser, it is 
not under the control of the browser itself. 

The advertising tag is itself embedded in a content web 40 
page. The advertising tag, as one of its components, refer- 
ences a JavaScript file (which contains a "script") stored on 
a distribution server. The JavaScript file, when executed, 
downloads and implements, through dynamic writing of 
applet tags, the Transition Sensor applet. This particular 45 
applet remains visually transparent to a user who displays, 
with his(her) browser, the HTML coding for that page. 
Specifically, when the JavaScript file is downloaded and the 
script it contains is then executed by the browser, the script 
dynamically writes a predefined number and combination of 50 
applet tags, i.e., which collectively form the Transition 
Sensor applet, into the retrieved web page content in lieu of 
the advertising tag. Subsequent execution of these tags, by 
the client browser, invokes the Transition Sensor applet. As 
discussed, the advertising tag also, as the other of its 55 
components, encapsulates a reference, i.e., a URL to a 
specific ad management server, typically sited on a third 
party advertising server, containing specific media, that 
collectively constitutes web advertisements, and accompa- 
nying player files. 60 

In particular, when executed, the Transition Sensor applet 
instantiates an Applet Registry, which is used for inter-applet 
communication. Thereafter, the Transition Sensor applet 
determines whether the AdController applet has been down- 
loaded to the browser disk cache or whether an updated 65 
version of this particular applet resides on a distribution 
server. If an updated version of this applet exists on the 
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distribution server relative to that previously downloaded to 
the browser disk cache or if this applet has not been 
download at all onto this cache, the Transition Sensor applet 
loads the AdController applet from the distribution server 
into the browser disk cache. The Transition Sensor applet 
then instantiates the AdController applet. Once this occurs, 
the Transition Sensor applet then establishes appropriate 
entries in the Applet Registry for itself and the AdController 
applet. 

The Transition Sensor applet then passes the URL of the 
ad management system, as specified in the advertising tag, 
to the AdController applet in order for the latter applet to 
request delivery of an advertisement, specifically an asso- 
ciated AdDescriptor file, originating from that system. The 
system then selects the advertisement to be delivered and, 
via the third party advertising server, so informs the AdCon- 
troller applet by returning the requested AdDescriptor file. 
For a given advertisement, this particular file, which is 
textual in nature, contains a manifest, i.e., a list, of: file 
names and corresponding web addresses of all media files 
that constitute content for that advertisement and all player 
files necessary to play all the media files; an order in which 
the various media files are to be played; and various con- 
figuration and other parameters need to configure and oper- 
ate the operation of each player in order for it to properly 
play a corresponding media file(s). The AdController then 
"politely" downloads, typically via the advertising distribu- 
tion server, the associated media and player files, as speci- 
fied in the AdDescriptor file — and to the extent they do not 
already reside on the hard disk of the client PC. As noted 
above, the Transition Sensor applet also monitors a click- 
stream produced by the current user to detect a user-initiated 
page transition and hence the start of an interstitial interval. 

Advantageously, the AdDescriptor file implements a data 
abstraction that totally separates the media and player files 
from the referring web page thus assuring that the adver- 
tisement content itself remains completely independent of 
the content web page that invoked its presentation. This 
abstraction permits our technique to provide a highly 
effective, generalized and very flexible mechanism for deliv- 
ering rich web advertisements, particularly those that require 
complex sets of media files and players. Through use of this 
abstraction, our technique is able to handle present and 
future media formats, regardless of their requirements, 
including proprietary streaming and other content delivery 
technologies that rely on Java applets as a delivery 
mechanism — all transparently to the user. Moreover, since 
the AdDescriptor file can specify media and player files for 
different browsers, operating systems and computing plat- 
forms then in use, our technique can readily function with a 
wide variety of different computing and browsing platforms. 

The Transition Sensor and AdController applets arc each 
implemented through appropriate Java classes and collec- 
tively persist, through storage in the browser disk cache, 
across different content pages within a site, across different 
web sites, and across successive browser sessions. Once 
either of these applets is completely downloaded, providing 
it is not subsequently flushed from the browser disk cache as 
the user navigates across web sites on the web, the files for 
that applet will be loaded from that cache, rather than being 
downloaded from the distribution server, the next time that 
applet is required, e.g., when the user next navigates, either 
during a current browser session or a subsequent session, to 
any content page that contains an advertising tag. 

Whenever the client browser encounters a next successive 
page containing an advertising tag, then the browser will 
first and automatically inquire with the distribution server to 
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ensure that executable code for the Transition Sensor applet, As a feature, our inventive technique advantageously 

if previously downloaded into the browser disk cache, has implements, in conjunction with its persistent agent 

not been superseded by an updated version. If such an approach, multi-threaded pipelining. By processing each 

updated version then exists, the browser will collectively different advertisement as a different thread, each one of a 

download updated files from the distribution server and 5 sequence of different processing operations can be 

replace, to the extent necessary, each Transition Sensor performed, effectively on a pipe-lined parallel basis, on 

applet file residing in the browser disk cache with its updated different sequentially occurring advertisements, thereby 

version. Alternatively, if the Transition Sensor applet has not enhancing a rate (increasing throughput) at which advertisc- 

been previously downloaded into the browser disk cache, ments can be que ued for playback. In addition, through such 

then the browser will download all the necessary files for the 30 pipelining, logging of a fully presented advertisement can 

Transition Sensor applet from the distribution server into occur ^ a j asl operation in a pipeline and essentially in 

that cache. The Transition Sensor applet, once executing, parallel either with: presentation of cached advertisement 

will load, through the browser, the AdController applet. To having its AdDescriptor file situated in the play queue 

do so, the browser will, if necessary, obtain an updated immediately behind that for the just presented 

version, from the distribution server, in the same manner as 15 advertisement, or with downloading and caching of a next 

it did for the Transition Sensor. As a result, any corrections successive advertisement, 
or enhancements made to the agent (specifically the Tran- 

sition Sensor and/or the AdController applets) since the BRIEF DESCRIPTION OF THE DRAWINGS 

agent was last downloaded to the client browser will be The teachings of the present invention can be readily 

automatically and transparently, from a user perspective, 2 q understood by considering the following detailed descrip- 

distributed to that browser and downloaded into the browser tion in conjunction with the accompanying drawings, in 

disk cache the next time the browser encounters a web page which: 

containing an advertising tag. By operating in this fashion, FIG. 1A depicts the correct alignment of the drawing 

the user is totally and advantageously relieved of any need sheets for FIGS. IB and 1C; 

to: both initially load and install an application program to 25 FIGS. IB and 1C collectively depict a high-level block 
obtain advertising and/or later update that program. diagram of an illustrative client-server distributed process- 
Furthermore, the agent advantageously persists and func- ing environment, implemented through the Internet, which 
tions transparently in background, independent and trans- embodies the teachings of our present invention, along with, 
parent to user navigation across pages on a common web site as pertinent to the invention, basic inter-computer actions 
and across web sites. The agent effectively implements a 30 that occur in that environment and associated client process- 
background process which runs in parallel with and is ing operations; 

transparent to normal HTML and HTTP operations imple- piG. ID depicts the correct alignment of the drawing 

mented by the client browser. snee ts for FIGS. IE and IF; 

Moreover, in sharp contrast to conventional server-based piGS. IE and IF collectively depict the same environ- 

accounting of web advertisements, our inventive technique 35 me nt as shown in FIGS. IB and 1C but showing a detailed 

provides highly accurate client-side accounting of each user version of agent download/instantiate/execute operations 50 

impression. Each log entry, produced by the AdController shown in the latter figures; 

applet, specifies a successful presentation of a complete FIG. 2 depicts the correct alignment of the drawing sheets 

advertisement at a client browser. This entry may include a f or pjqs 2 A and 2B* 

source of the ad content, i.e., in terms of the URL of the 40 FIGS 2A and 2B ' collectively depict generalized web 

associated ad management system, a title of the advertise- HTML code 35, specifically inclusion of advertising 

ment and the URL of the referring web page. Other client- . An u- u * #i • i j 

. , . - . , b , . tag 40, which transparently invokes our invention, and 

side information can be measured and included in each .° _ « - * A ■ n., „ _ , 

r . - . , . . , , changes which our invention dynamically makes to that 

entry, such as: an amount of tune during which the adver- , c u u *■ c t c i * 

A . J , . r .... code, specifically substitution of Transition Sensor applet 

tisement was rendered by the browser (presumably during 45 210 for ( 40 lo ieW 35, m order U) download and 

which the user dwelled on the advertisement); as well as an render web advertisement 

identification, in terms 01 a URL, or a content web page to >, , . , . , . , , , * ,. 

which the user next navigated (particularly if the user K FIG * 3 d « ' ^^vcl block diagram of client PC 5 

reached that page through a hoUink displayed in the sho ™ l ° ? GS - 1B and ^ and ^ A . 

advertisement). Subsequently, the AdController applet 50 F 1 IG * 4 depiCtS 3 hl S h -} evel Mock dia S ram of 

uploads the log entries to the advertising server. These application programs 400 resident within client PC 5 shown 

entries will be collectively processed, as needed, to permit in HG * ^ 

shared ad revenues from web-based advertisers to be prop- F,G - 5 de P icts a high-level block diagram of AdController 

erly allocated among different web page content providers. a g ent 420 shown in FIG - 4 > which implements our present 

Advantageously, our inventive technique, by totally 55 inventl0n J 

decoupling referring web page content from its correspond- FIG * 6 depicts the correct alignment of the drawing sheets 

ing advertising content, easily permits an advertiser to ^ or FIGS- 6A and 6B; 

change or update any of its advertisements by just FIGS. 6A and 6B collectively depict a high-level flow- 
modifying, as needed, appropriate media and AdDescriptor chart of processing operations 600 performed by AdCon- 
files that reside in the third-party advertising management 60 trailer agent 420 shown in FIG. 5; 

system. Since a referring web page merely incorporates an FIG. 7 depicts a high-level block diagram of basic pro- 
advertising tag totally devoid of advertising content, no cessing threads that implement AdController applet 424 
changes whatsoever need to be made to that page. Hence, which, as shown in FIG. 4, forms part of AdController agent 
use of our inventive technique substantially reduces the 420; 

burden, time and cost associated with maintaining and 65 FIG. 8 depicts a high-level flowchart of processing opera - 

updating web -based advertising over that conventionally tions 800 performed by AdController applet 424 shown in 

required. FIG. 7; 
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FIG. 9 depicts the correct alignment of the drawing sheets advertisements to a client personal computer (PC) connected 

for FIGS. 9 A and 9B; to the Internet, where specifically a client browser executing 

FIGS. 9A and 9B collectively depict a flowchart of in the PC is used to download and render web pages from a 

processing operations 900 performed by AdController remote networked Internet accessible web server. Clearly, 

applet 424, shown in FIG. 7, specifically for processing an 5 after considering the ensuing description, anyone skilled in 

advertisement; me art w iU readily appreciate how the teachings of our 

FIG. 10 depicts inter-applet events that occur within invention can be easily incorporated into any client-server or 

AdController agent 420 during execution of Transition Sen- other similar distributed processing environment in which a 

sor applet 422' client can encompass not only a specific computer connected 

n „ . * . , . , , r . . 10 to a network but a software process that possesses network 

FIG. 11 depicts a high-level block diagram of basic C0Mectivit , 0 another such ^ and te informa . 

processing threads that implement Iransition Sensor applet , ion from and ^ obtains supp , ied by 

422 which, as shown in FIG. 4, forms part of AdController ^ | atler 
agent 420; 

™« , . , r . We will first present an overview of our invention, par- 

,™E 1C V hl ^™ 1 fl^hart of processing 15 ^ me CQntext Qf ^ use wim M Imemet web 

operation 1200 performed by Transition Sensor applet 422 bfOWSer m a ^ pc foUowed by describing each basic 

shown in FIG. 11; component of its implementation. 

FIG. 13 depicts a high-level block diagram of Ad Loader 

process 1300 which can be used to provide advertiser A. Overview 

control over various functions, for advertisement play and 20 

logging, implemented by AdController applet 424; A & eneral deployment of our invention in an Internet 

CTr 1j(J . . u - u i ,li , j • rAJT^- i- environment is collectively shown in FIGS. IB and 1C, with 

FIG. 14 depicts a high-level Mock diagram of Ad Pipeline , , , r r 4 , . . ' 

e^c *u * • • i . j i . r r i * ii a detailed view of a portion of the inter-processor agent 

545 that is implemented by and forms part of AdController , , a ■ . • eft L • c 

i * A-** u • t-ij /-> a download/instantiation operations 50 shown in these figures 

applet 424 shown in FIG. 4; , . , . t , . *1 , ir? _ & . 

rr » s being depicted in FIGS. IE and IF. The correct alignment of 

FIG. 15 depicts a high-level block diagram of Ad Pro- the drawing sheets for FIGS 1B and 1C and 1E and 1F ^ 

ducer process 1500 that is executed by Ad Pipeline 545 showQ in nGS 1Aand 1D> respectively. FIGS. 2Aand 2B, 

shown in FIG. 14; for wn i cn tne correct alignment of the drawing sheets for 

FIG. 16 depicts a high-level block diagram of Ad Loca- these figures is shown in FIG. 2, collectively depicts gen- 

tion process 1600 that is also executed by Ad Pipeline 545 30 eralized web page HTML code which transparently invokes 

shown in FIG. 14; our invention, and changes which our invention dynamically 

FIG. 17 depicts a high-level block diagram of Ad Down- makes to that code in order to download and render web 

loader process 1700 that is also executed by Ad Pipeline 545 advertisements. For a understanding, the reader should 

shown in FIG. 14; simultaneously refer to FIGS. IB and 1C, IE and IF, and 2A 

FIG. 18 depicts a flowchart of stop method 1800 invoked 35 and 2B throughput the following discussion, 

by Transition Sensor applet 422 shown in FIG. 4; As shown, client PC 5, upon which client browser 7 

FIG. 19 depicts a flowchart of start method 1900 invoked executes, is connected through communication link 9 to 

by Transition Sensor applet 422 shown in FIG. 4; and Internet 10. Browser 7 is a conventional web browser, such 

cir^ inj Q „'„„ « * c « i*n *t~ ai r\ as Internet Explorer or Netscape Navigator commercially 

FIG. 20 depicts contents of actual illustrative AdDescnp- , , e w - X f- xr J 

tor file 200(1 for use in interstitially rendering a PointCast 40 i Va,lab e fr0m ^'crosoft Corporation or Netscape 

type Java advertisement through our present invention. ^t™' res P ect 'y^ 1 >' K PreIerab ly. ° r re f « that w11 

r . 6 v shortly become clear, that browser should preferably support 

To facilitate understanding, identical reference numerals dynamic writing of applet tags. Though, for ease of illus- 

have been used, where possible, to designate identical trating inter-computer actions, we depicted Internet 10 as 

elements that are common to the figures. 45 having portions 10a and 10 B , we will collectively refer to 

DETAILED DESCRIPTION both P ortions as sim Ply Internet 10. Web server 13, 

connected, via link 11, to Internet 10 represents any web 

After considering the following description, those skilled HTTP (hypertext transfer protocol) server. This server, in 

in the art will clearly realize that the teachings of our present response to a request from web browser 7 to fetch a specific 

invention can be utilized in any networked client-server 50 file, downloads that file, using conventional TCP/IP proto- 

environment in which advertising or other information is to cols (transmission control protocols/internet protocols), 

be presented to a user during interstitial intervals, i.e., during through the Internet to browser 7. Browser 7 will, in turn, 

a transition between successively displayed web pages. Such render that file typically on a monitor to a user situated at the 

an environment can encompass the Internet or an intranet, or client PC. 

any client-server environment in which a client browser 55 Advertising distribution HTTP server (also referred to as 

(regardless of whether that browser executes on a dedicated "agent" server) 15 is connected, via communications link 

client computer or not) is used to access and download web 17, to Internet 10 and stores files that collectively implement 

pages or, more generally speaking, files through a network a predefined agent, specifically, a light weight Java applet, 

communication channel (link) from a server (again regard- This agent (referred to herein as the "AdController" agent) 

less of whether that server executes on a dedicated computer 60 transparently pre-loads itself, as well as media rich adver- 

or not). In that regard, the server can be a separate software tising content, into a local hard disk cache associated with 

application which executes on any computer in the net- the browser ("browser disk cache") on client PC 5. Server 15 

worked environment, even if that computer is itself a client downloads the AdController agent in a manner to be 

to another server in the network. described below, to client browser 7. This agent, once 

For purposes of simplicity and to facilitate reader 65 instantiated and started, then transparently and politely 

understanding, we will discuss our present invention in the downloads (actually pre-loads) advertisements into the 

illustrative context of use in rendering interstitial web-based browser disk cache, and subsequently plays each of those 
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advertisements, on an interstitial basis, in response to a click 
stream generated by the user as (s)he navigates, through use 
of browser 7, between successive web pages. Such hard disk 
caching advantageously circumvents variable latency and 
erratic play associated with conventional streamed and static 5 
media delivered over the Internet. The agent enables rich 
advertising to be presented in a highly-controlled fashion, 
resulting in user experiences approaching that of CD-ROM. 

Third-party ad HTTP server 20, connected to Internet 10 
via, e.g., communications links 18 and 23, hosts ad man- io 
agement system 25. In essence and as discussed in detail 
below, this system, in response to a request originating from 
the AdController agent executing in browser 7, selects a 
given advertisement and then downloads, in a "polite" 
manner controlled by the agent, media and player files that 15 
form that advertisement to the agent for storage in the 
browser disk cache. Inasmuch as Java applets are currently 
restricted under constraints inherent in the Java program- 
ming language itself to retrieving files from an identical 
Internet host that served the applet itself, the request for an 20 
advertisement to system 25 as well as resulting media and 
player files served by system 25 are routed through agent 
server 15 as a proxy server. 

Advantageously, our inventive technique completely 
"decouples" advertising content from a web content page 25 
(also hereinafter referred to as a "referring" page). This, in 
turn, permits our technique to render media-rich advertise- 
ments without requiring inclusion of any advertising content 
into a referring web page. This "decoupling" is effectuated 
through inclusion of an HTML tag into a content web page, 30 
which when the latter is downloaded, interpreted and 
executed by the browser, effectively loads and instantiates 
the agent and then retrieves advertisement files from an ad 
management system specified in the tag. Thus, advertising 
files (both media and player files) can be maintained totally 35 
independently of their referring web page(s), with advanta- 
geously any changes made to the former having no effect on 
HTML coding contained in the latter. 

In particular, HTML tag 40 (which, where necessary, to 
distinguish this tag from other HTML tags, will also be 40 
referred to hereinafter as an "advertising tag") is embedded 
by a content providers) into HTML code that constitutes 
each referring web page, e.g., here page 35. Generally, the 
position of this tag relative to existing HTML code (shown 
as HTML code portions 35 A and 35 B in FIGS. 2A and 2B) 45 
for this page is not critical. Advantageously, very rarely, if 
ever at all, do any changes need to be made to these code 
portions to accommodate the tag. As shown and as repro- 
duced in Table 1 below, this tag, which typically consumes 
one line in a web page, implements a script. 50 

<SCRIPT SRC=http://unicast.com/loadad.js> 

AdServer="http://AdManagement system" 

</SCRIPT> 

TABLE 1— ADVERTISING TAG 55 

One portion of the advertising tag ("SRC=http:// 
unicast.com/loadad.js"), when executed by the browser, 
downloads a JavaScript file (named "loadad.js") from the 
agent server. This file, in turn, is then interpreted and 60 
executed, as a script, by the browser. The effect of executing 
this script, as symbolized by block 200 shown in FIGS. 2A 
and 2B, is to substitute applet tags, dynamically written by 
the script, into the referring web page in lieu of advertising 
tag 40 so as to form a modified web page, here referring 65 
content page 35', residing in the browser disk cache. The 
script, by invoking a feature associated with dynamic 
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writing, completely hides these tags from view should the 
user then display HTML source code for page 35' with his 
browser. This, in turn, hinders the user, to a certain degree, 
from readily ascertaining the source of the agent and ad 
management systems. Collectively, these applet tags form 
Transition Sensor applet 210. This script, as described in 
detail below and is reproduced in Table 2 below, when 
interpreted and executed by a Java virtual machine (Java 
interpreter) resident in the browser persistently loads and 
then instantiates the Transition Sensor itself which, in turn, 
loads and instantiates the remainder of the agent in the client 
browser. 

<applet code- 
"com.unicast. adcontroller. tools. TransitionSensor" 

codebase="http://www.unicast.com/java/classes/" 

align="baseline" width="0" height="0" name« 
"TransitionSensor" 

archive=" adcontroller.jar"> 

<param name«"adURL" 

value="http://www.unicast.com/media/fireworks„01_ 
ad__descriptor.txt"> 

<param name«"cabbase" value =" adcontroller. cab"> 
</applet> 

TABLE 2— TRANSITION SENSOR APPLET 

The value of attribute CODE in the Transition Sensor 
applet specifies a Java executable that will be executed by 
the client browser, when it renders this applet, to launch the 
Transition Sensor. The executable, implemented through an 
appropriate Java class, was originally compiled from its 
associated Java source code file. Tags labeled "<WIDTH>" 
and "<HEIGHT>" jointly specify a rectangular portion of a 
web page, as displayed by browser 7, in which the applet 
will be rendered. Since, here that portion is non-existent, 
nothing will be rendered. Applets, such as this one, can be 
delivered transparently over the Internet to the client PC and 
require no user-assisted installation. 

Another portion of the advertising tag ("AdServer= 
"http://AdManagement_system") references a URL of a 
particular ad management system (where 
"AdManagement__system" represents a web address (URL) 
of that particular system), here illustratively system 25, from 
which the agent is to download an advertisement. As will be 
seen below, the Transition Sensor applet, during its 
execution, passes this URL, as part of an advertising down- 
load request, to the remainder of the AdController agent to 
subsequently download appropriate advertising files, also as 
described below, from that system necessary to interstitially 
play an advertisement. 

If advertisements are to play on client browsers 
(specifically Microsoft Internet Explorer version 3) that do 
not support dynamic writing of applet tags, then applet 210 
would need to be inserted by content providers into each 
referring web page in lieu of advertising tag 40. 
Unfortunately, Transition Sensor applet 210 identifies both 
the agent server, and an actual advertisement in terms of a 
URL of its source components (through contents of an 
"AdDescriptor" file — which will be discussed in detail 
below — specified in this applet). Since browser technology 
continues to rapidly advance with most users continually 
upgrading their browsers, most browsers now in use, and in 
a very short time nearly all such browsers, will support such 
dynamic writing. Hence, we see little, and very shortly 
essentially no need, to embed applet 210 into any referring 
web pages, thus minimizing ad insertion cost, effort and time 
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while restricting disclosure of the agent server and adver- 
tisement source information. 

The agent, during its execution, "politely" and transpar- 
ently downloads advertising files (media, and where neces- 
sary player files), originating from ad management system 5 
25 for a given advertisement into browser disk cache (with 
the media files also being written into browser RAM cache) 
and subsequently plays those media files through the 
browser on an interstitial basis and in response to the user 
click-stream. 1° 

Advantageously, the agent operates independently, in the 
client browser, of the content in any referring web page. 
Once loaded and started, the agent executes in parallel, with 
standard browser functionality, continually and transpar- 
ently requesting and downloading advertisements to a 15 
browser disk cache residing on a local hard disk ("browser 
disk cache"), as well as in the case of media files into 
browser RAM cache, in a client computer (e.g., personal 
computer — PC) and interstitially playing those advertise- 
ments. 20 

Now, with the above in mind and specific reference to 
FIGS. IB and 1C, we will now describe the basic inter- 
computer actions associated with use of our invention, as 
well as the basic attendant processing steps that occur in the 
client PC. 

To begin a browsing session, the user first invokes client 
browser 7. Once the browser is executing, the browser 
obtains, as an initial web page — selection of this page being 
referenced by numeral 31, an address either of a prior 30 
so-called "default" content page previously specified by the 
user and having its URL stored in the browser or of a content 
page manually entered by the user The client browser then 
issues, as symbolized by block 33, a request to fetch a file 
for that page; with the request containing a URL of that page 35 
(i.e., its complete web address including its file name). We 
assume for simplicity that the file for that page resides on 
web server 13. We also assume that page 35 is being 
requested which will invoke an associated interstitial adver- 
tisement in accordance with our invention. In response to the 40 
request routed to server 13 — as symbolized by line 34, this 
particular server downloads, as symbolized by line 36, to 
client PC 5 a file for page 35, where the coding stored in this 
file contains advertisement tag 40. Illustrative contents of 
this tag are shown in dashed block 45, as well as in FIGS. 45 
2A and 2B. 

Once this file is received as shown in FIGS. IB and 1C, 
browser 7 interprets and then executes, as symbolized by 
block 52, the HTML code in page 35, which includes tag 40 
and thus undertakes the actions shown in agent download/ 50 
instantiate/execute operations 50. These operations eventu- 
ally result in the AdController agent being downloaded, 
instantiated and started in the client browser. Generally 
speaking, the browser in response to executing the adver- 
tising tag, issues a request, as symbolized by line 54, to agent 55 
server 15 to download the AdController agent. Through 
various inter-process operations, as shown in further detail 
in FIGS. IE and IF and which will be described below 
shortly, server 15 accesses and downloads, as symbolized by 
line 56, the needed files to install the AdController agent to 60 
execute under browser 7 on the client PC. Once files for the 
agent are downloaded to the browser disk cache on the client 
PC, the browser then instantiates and starts the agent 
executing, as symbolized by block 58. Operations 50 effec- 
tively conclude once the agent begins executing. 65 

Now referring to operations 50 as shown in further detail 
in FIGS. IE and IF, upon entry into these operations, 
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browser 7 executes, as symbolized by block 110, advertising 
tag 40. The browser then issues a request, as symbolized by 
line 115, to agent server 15, to download a JavaScript file 
(named, e.g., "loadad.js") specified in the request. This file 
is specified as the first portion of the advertising tag. In 
response to this request, server 15 downloads, as symbolized 
by line 120, this particular file onto browser 7 where that file 
is cached appropriately. Once the file is fully downloaded, it 
is interpreted and executed by a Java virtual machine (a Java 
interpreter integrated into the browser and which generates 
code compatible with and executable by the browser). As 
indicated by block 125, the browser then executes the 
interpreted code for the script which, in turn, dynamically 
writes applet tags — in the manner generally shown in FIGS. 
2A and 2B and described above — into web page 35 in Leu 
of the advertising tag. These tags, which collectively form 
Transition Sensor applet 210, include a reference to a 
specific ad management system as specified in the second 
portion of advertising tag 40. 

Once these tags are dynamically written into content web 
page 35 (to yield modified version 35' shown in FIGS. 2 A 
and 2B), Transition Sensor applet 210 is instantiated and 
then executed. In particular, browser 7 determines whether 
executable code for the Transition Sensor applet has been 
previously downloaded to the browser disk cache. If this 
code has not been downloaded or an updated version of this 
code exists on agent server 15, the browser issues, as 
symbolized by line 130, a request to download a latest 
version of the Transition Sensor executable code from the 
agent server. Server 15, in response to this request, 
downloads, as symbolized by line 135, file(s) for the latest 
version of the transition sensor code to the browser which, 
in turn, stores these file(s) into the browser disk cache. 
Thereafter as symbolized by block 140, the browser instan- 
tiates and starts execution of the Transition Sensor applet. 
This latter applet, as part of its initial execution, instantiates 
an Applet Registry. This registry provides a mechanism, 
within the agent, for inter-applet communication between 
the constituent Transition Sensor and AdController applets. 

Thereafter, the Transition Sensor applet attempts to load, 
also as symbolized by block 140, the AdController applet, 
through the browser, from the browser disk cache. To do so, 
the browser first determines whether the AdController applet 
has been downloaded to the browser disk cache or whether 
an updated version of this particular applet resides on agent 
server 15. If an updated version of this applet exists on the 
agent server relative to that previously downloaded to the 
browser disk cache or if the AdController applet has not 
been download at all into this cache, the browser issues a 
request, as symbolized by line 150, to download a latest 
version of the AdController applet from agent server 15. 
Server 15, in response to this request, downloads, as sym- 
bolized by line 155, file(s) for the latest version of the 
AdController applet to the client browser which, in turn, 
stores these file(s) into the browser disk cache. Lastly, as 
symbolized by block 160, the Transition Sensor applet then 
instantiates and starts the AdController applet; and thereafter 
establishes appropriate entries in the Applet Registry for 
itself and the AdController applet. 

Returning to FIGS. IB and 1C, once operations 50 have 
completed, such that the agent is executing under browser 7, 
the AdController applet issues, as symbolized by block 60, 
a request, via agent server 15, to download an AdDescriptor 
file from the ad management system, e.g., ad management 
system 25, specified in advertising tag 40. This request 
contains the URL of the ad management system contained in 
advertising tag 40. Currently, Java applets are restricted 
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under constraints inherent in the Java programming lan- 
guage itself to retrieving files from an identical Internet host 
that served the applet itself. As such, rather than directing 
this request to advertising server 20, on which ad manage- 
ment system 25 resides, this request, as symbolized by line 5 
62, is addressed to agent server 15, which serves as a proxy 
server between client PC 5 and advertising server 20. Both 
the request and resulting advertising (including media and 
player) files will be served to the client PC through agent 
server 15. As such, once the request has been received by the 30 
agent server, this server passes the request onward, as 
symbolized by line 64, to advertising server 20. 

In response to this request for an AdDescriptor file, ad 
management system 25 then selects a specific advertisement 
to be delivered to client PC 5. This selection can be selected 35 
on a predefined or random basis, or based on user preference 
or other user-specific information previously collected from 
and associated with the user then operating browser 7. Such 
user-specific information, such as prior buying patterns, 
could have been appropriately pre-collected at the client PC, 2 o 
previously uploaded to ad management system 25 and 
processed there such that, upon receipt of the AdDescriptor 
request, system 25 would then select and download an 
appropriate advertisement specifically targeted to the user 
then situated at the client PC. In any event, once system 25 25 
selects the advertisement, through whatever selection metric 
it employs, the corresponding AdDescriptor file is then 
downloaded, as symbolized by line 66, to agent server 15 
(here being a proxy server) which, in turn, as symbolized by 
line 68, supplies that file to the AdController agent then 30 
executing under web browser 7. 

To digress slightly, for the selected advertisement, the 
AdDescriptor file is a text file that contains a manifest, i.e., 
a list, of file names and corresponding network locations 
(URLs) at which these files reside, and player instructions 35 
and configuration parameter values necessary to play the 
entire advertisement through web browser 7 to the user. FIG. 
20 shows contents of typical AdDescriptor file 2000 for a 
PointCast Java advertisement. Specifically and as shown in 
section 4C of file 2000, this AdDescriptor file lists file names 40 
with partial addresses on the ad management system of all 
media files that constitute content for that advertisement, 
and, in section 1 of this file, all Java player files necessary 
to play all the media files. This file also respectively 
specifies, here shown in sections 3 and 4B, an order in which 45 
the various media files are to be played, and various con- 
figuration parameters needed to properly configure the 
operation of each player to play each corresponding media 
file. 

The AdDescriptor file implements a data abstraction that 50 
totally separates the media and player files from the referring 
web page, here page 35, thus assuring that the advertisement 
content itself remains completely independent of the content 
web page that invoked its presentation. This abstraction 
permits our technique to provide a highly effective, gener- 55 
alized and very flexible mechanism for delivering rich web 
advertisements, particularly those that require complex sets 
of media files and players. Through use of this abstraction, 
our inventive technique can handle present and future media 
formats, regardless of their requirements, including propri- 60 
etary streaming and other content delivery technologies that 
rely on Java applets as a delivery mechanism — all transpar- 
ently to the user. Moreover, the AdDescriptor file can 
contain separate listings (though not contained in file 2000 
shown in FIG. 20) that delineate media and player files for 65 
different browsers, client operating systems or computing 
platforms (to the extent any of these require different ver- 
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sions of the media and/or player files) then in use. As such, 
our technique can readily function with a wide variety of 
different client computers and browsing platforms. 

Once the AdDescriptor file is downloaded to the client 
PC, via agent server 15, the AdController then "politely" 
downloads, as symbolized by block 70 shown in FIGS. IB 
and 1C, into the browser disk cache each media and player 
file, as specified in the AdDescriptor file — to the extent that 
file does not already reside on the hard disk of the client PC. 
Through so-called "polite" downloading, media and player 
files are downloaded to browser 7 during browser idle time 
intervals, with the downloading suspended during each 
ensuing interstitial interval after the user instructs browser 7 
to navigate to a new content web page. In this manner, while 
a fully downloaded advertisement is interstitially played 
from browser cache, the new content page is downloaded 
over the full bandwidth of communications link 9. 
Advantageously, the communications link is freed during 
each interstitial interval to just carry web page content, 
thereby expediting download of content pages. If, due to the 
occurrence of an interstitial interval, the AdController applet 
suspends downloading of an advertisement file, then upon 
termination of this interval, this applet then resumes down- 
loading at a location in that file at which downloading had 
stopped, thus conserving communication bandwidth and 
reducing download time. 

In particular, as part of the operations symbolized by 
block 70, the AdController applet determines which files, of 
those listed on the AdDescriptor, do not then reside on the 
hard disk of client PC 5. Once it has made that 
determination, this applet issues a request, as symbolized by 
line 72, to agent server 15, to fetch a first one of these files. 
The agent server, again serving as a proxy server, issues a 
request, as symbolized by line 74, to fetch this file from a 
networked server, anywhere on Internet 10, on which that 
file resides. For simplicity, we assume that all such files 
reside on server 20 and are accessible through ad manage- 
ment system 25. Hence, system 25, via server 20, issues a 
response, as symbolized by line 76 to agent server 15, 
containing this first advertisement file. The agent server, in 
turn and as symbolized by line 78, downloads this particular 
file to client browser 7 for storage in the browser disk cache. 
Downloading of advertisement files continues in this manner 
until, as symbolized by line 88, a last required file for the 
advertisement has been downloaded, via agent server 15, to 
the browser disk cache on client PC 5. 

As the advertisement files for a common advertisement 
are being downloaded, the Transition Sensor applet also 
monitors, as symbolized in block 90, a click-stream pro- 
duced by the current user so as to detect a user-initiated page 
transition. Once such a transition occurs, usually caused by 
a user engendered mouse click, and hence an interstitial 
interval starts, the AdController applet plays, also as sym- 
bolized by block 90, a fully cached advertisement (assuming 
all its media and player files have been downloaded) in the 
manner specified in its associated AdDescriptor file and 
using the players specified therein. Also, at the inception of 
the interstitial interval, the browser issues, also as symbol- 
ized by block 90, a request to fetch the next successive web 
page to which the user desires to transition. Once the 
advertisement has fully played, or until the next successive 
content web page is fully downloaded and assembled, or a 
user has closed an advertisement window, whichever occurs 
first (assuming the AdDescriptor file specifies that the adver- 
tisement can be prematurely terminated), then control is 
returned, as symbolized by path 94, to the client browser to 
await completion of the download and interpretation of 
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HTML code that forms that next content page and subse- 
quent execution, of an advertising tag therein to invoke 
agent download/instantiate/execute operations 50 for that 
page; and so forth. 

The Transition Sensor and AdController applets are each 
implemented through appropriate Java classes and collec- 
tively persist, through storage in the browser disk cache, 
across different content pages within a site, different web 
sites, and successive browser sessions. Once either of these 
applets is completely downloaded through operations 50, 
providing that applet is not subsequently flushed from the 
browser disk cache as the user navigates across web sites on 
the web, the files for that applet will be loaded from that 
cache, rather than being downloaded from agent server 15, 
the next time that applet is required, e.g., when the user next 
navigates, either during a current browser session or a 
subsequent session, to any successive content page that 
contains advertising tag 40. 

Whenever client browser 7 encounters a next successive 
content page containing advertising tag 40, then the browser, 
will first and automatically inquire with agent server 15 to 
ensure that executable code for the Transition Sensor applet, 
if previously downloaded into the browser disk cache, has 
not been superseded by an updated version. If such an 
updated version then exists, the browser will collectively 
download updated files from the agent server and replace, to 
the extent necessary, each Transition Sensor applet file 
residing in the browser disk cache with its updated version. 
Alternatively, if the Transition Sensor applet has not been 
previously downloaded into the browser disk cache, then the 
browser will download all the necessary files for the Tran- 
sition Sensor applet from the agent server into that cache. 
The Transition Sensor applet, once executing, will load, 
through the browser, the AdController applet. To do so, the 
browser will, if necessary, obtain an updated version, from 
the agent server, in the same manner as it did for the 
Transition Sensor. As a result, any corrections or enhance- 
ments made to the agent (specifically the Transition Sensor 
and/or the AdController applets) since the agent was last 
downloaded to the client browser will be automatically and 
transparently, from a user perspective, distributed to that 
browser and downloaded into that disk cache the next time 
the browser encounters a web page containing an advertising 
tag. By operating in this fashion, the user is totally and 
advantageously relieved of any need to: both initially load 
and install an application program to obtain advertising 
and/or later update that program. 

Specifically, cross page persistency of the Transition 
Sensor agent is accomplished by using a Java "singleton" 
design. A singleton design allows only a single object to ever 
be created and is accomplished by declaring a Java class as 
static. Since all applets run in a same instance of a Java 
virtual machine, therefore all applets and their associated 
code share all static class variables. A static Applet Registry 
class is instantiated automatically by the Transition Sensor 
applet at its run time and, by implementing the Applet 
Registry, provides all inter-applet communication between 
the Transition Sensor and the AdController applets and their 
threads. The Applet Registry class implements a "loadAd- 
Controller" method which, in turn, instantiates the persistent 
AdController applet. Through this method, the Transition 
Sensor applet downloads the AdController applet only if the 
latter applet has either been updated, relative to that version 
of this applet then resident in the browser disk cache, or does 
not then reside on the browser disk cache. The AdController 
applet then instantiates all its own threads that collectively 
implement transparent advertisement downloading and play 
mechanisms. 
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The AdController applet is itself created by an Applet 
Registry singleton object and creates all other objects that 
collectively constitute a run time agent execution module. 
This applet extends standard applet class definitions by 

5 over-riding standard Java applet init (initialize), start, run, 
stop and destroy life cycle methods, conventionally imple- 
mented in the client browser, with corresponding substitute 
methods. The substitute stop method ensures that a tradi- 
tional response provided by the browser of halting execution 

10 for either the AdController applet does not occur whenever 
the browser calls the stop method to terminate the lifecycle 
of this applet; hence, advantageously providing persistence 
to the agent across successive content pages. Consequently, 
the agent continues executing until the user terminates 

is execution of (closes) the browser itself. 

Thus, the agent persists and functions transparently in 
background, independent and transparent to user navigation 
across pages on a common web site and across web sites. In 
that regard, the agent effectively implements a background 

20 process which runs in parallel with and is transparent to 
normal HTML and HTTP operations implemented by the 
client browser. 

To significantly simplify the description and the accom- 
panying drawings, we have intentionally omitted from this 

25 discussion specific Java classes that constitute the AdCon- 
troller agent as well as, to increase a rate at which adver- 
tisements can be queued for playback, an accompanying 
software architecture for processing these classes on a 
multi-threaded pipelined basis. Such details are conven- 

30 tional in nature; hence, their use in implementing our present 
invention would be readily apparent to any one skilled in the 
art. 

B. Client PC 

35 

FIG. 3 depicts a block diagram of client PC 5. 
As shown, the client PC comprises input interfaces (I/F) 
320, processor 340, communications interface 350, memory 
330 and output interfaces 360, all conventionally intercon- 

40 nected by bus 370. Memory 330, which generally includes 
different modalities, including illustratively random access 
memory (RAM) 332 for temporary data and instruction 
store, diskette drive(s) 334 for exchanging information, as 
per user command, with floppy diskettes, and non-volatile 

45 mass store 335 that is implemented through a hard disk, 
typically magnetic in nature. Mass store 335 may also 
contain a CD-ROM or other optical media reader (not 
specifically shown) (or writer) to read information from (and 
write information onto) suitable optical storage media. The 

50 mass store stores operating system (O/S) 337 and applica- 
tion programs 400; the latter illustratively containing 
browser 7 (see, e.g., FIGS. IB and 1C) which implements 
our inventive technique. O/S 337, shown in FIG. 3, may be 
implemented by any conventional operating system, such as 

55 the WINDOWS NT, WINDOWS 95, or WINDOWS 98 
operating system ("WINDOWS NT", "WINDOWS 95" and 
"WINDOWS 98" are trademarks of Microsoft Corporation 
of Redmond, Wash.). Given that, we will not discuss any 
components of O/S 337 as they are all irrelevant. Suffice it 

60 to say, that the browser, being one of application programs 
400, executes under control of the O/S. 

Incoming information can arise from two illustrative 
external sources: network supplied information, e.g., from 
the Internet and/or other networked facility, through com- 

65 munication link 9 to communications interface 350, or from 
a dedicated input source, via palh(es) 310, to input interfaces 
320. Dedicated input can originate from a wide variety of 
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sources, e.g., an external database. In addition, input 
information, in the form of files or specific content therein, 
can also be provided by inserting a diskette containing the 
information into diskette drive 334 from which client PC 5, 
under user instruction, will access and read that information 5 
from the diskette. Input interfaces 320 contain appropriate 
circuitry to provide necessary and corresponding electrical 
connections required to physically connect and interface 
each differing dedicated source of input information to client 
PC 5. Under control of the operating system, application 3Q 
programs 400 exchange commands and data with the exter- 
nal sources, via network connection 9 or path(es) 310, to 
transmit and receive information typically requested by a 
user during program execution. 

Input interfaces 320 also electrically connect and interface 
user input device 395, such as a keyboard and mouse, to 35 
client PC 5. Display 380, such as a conventional color 
monitor, and printer 385, such as a conventional laser 
printer, are connected, via leads 363 and 367, respectively, 
to output interfaces 360. The output interfaces provide 
requisite circuitry to electrically connect and interface the 20 
display and printer to the computer system. 

Furthermore, since the specific hardware components of 
client PC 5 as well as all aspects of the software stored 
within memory 335, apart from the modules that implement 
the present invention, are conventional and well-known, 25 
they will not be discussed in any further detail. Generally 
speaking, agent server 15 and third-party ad server 20 each 
has an architecture that is quite similar to that of client PC 
5. 

C. Software 30 
1. Application Programs 400 

FIG. 4 depicts a simplified high-level block diagram of 
application programs 400 resident within the client PC. 

As shown, the application programs, to the extent 
relevant, contain browser 7 and resident JAVA player files 35 
410, i.e., files for JAVA media players that have previously 
been installed onto the hard disk of the client PC. These 
players may illustratively include audio, streaming audio, 
video and multi-media players. 

Browser 7 contains AdController agent 420, when it has 40 
been fully loaded for execution into browser cache, browser 
disk cache 430 and Java virtual machine 440 (which has 
been discussed above to the extent relevant). As noted, this 
agent persists whenever the user causes browser 7 to tran- 
sition across different web content pages or different web 45 
sites, and functions independently and transparently of any 
such pages and sites. The AdController agent includes applet 
registry 426 for facilitating inter- applet communication 
within the agent. 

The AdController agent contains two applets: Transition 50 
Sensor applet 422 and AdController applet 424 (also 
referred to as applet 210 in FIG. 2B). As discussed above, 
the Transition Sensor applet accomplishes three basic func- 
tions. First, this applet loads, instantiates and starts the 
AdController applet. Second, the Transition Sensor applet 55 
communicates an Internet address of an advertising server, 
here server 20, to request an advertisement, specifically an 
AdDcscriptor file therefor, that is to be downloaded and 
subsequently presented. Lastly, the Transition Sensor applet, 
through associated click-stream monitoring (performed by a 60 
Transition Sensor implemented by this applet), determines 
when a user situated at client browser 7 undertakes an 
affirmative action, such as, e.g., causing a mouse click, to 
request a next successive web page be downloaded and 
rendered, and so notifies the AdController agent of that 65 
event. This event signals a start of an ensuing interstitial 
interval. 
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AdController applet 424, which is not embedded in any 
content page, executes under but is not controlled by 
browser 7. This applet, also as discussed above, accom- 
plishes several basic functions. First, it creates all other 
objects that collectively form a run time agent execution 
module for the agent. As noted above, this includes extend- 
ing standard Java applet class definitions by over-riding 
standard Java applet init, start, run, stop and destroy life 
cycle methods. Second, the AdController applet "politely" 
downloads advertising (including media and, where 
necessary, player) files, through the client browser executing 
at a client computer, into browser disk cache and in a manner 
that is transparent to a user situated at the browser. Lastly, 
the AdController applet interslitially plays advertisements 
through the client browser in response to the user click- 
stream associated with normal user navigation across dif- 
ferent web pages. 

Browser disk cache 430 stores downloaded AdDescriptor 
files 433 and accompanying and downloaded media and 
player files 437. 
2. AdController Agent 420 

FIG. 5 depicts a high-level block diagram of AdController 
agent 420. 

As shown, the agent specifically contains Transition Sen- 
sor applet 422, AdController applet 424 and applet registry 
426. 

As discussed generally above, the Transition Sensor 
applet implements, as one of its functions, a transition sensor 
which detects, through user navigation click-stream 
monitoring, a user-initiated transition to a new web page, 
and produces, in response, a corresponding Transition Sen- 
sor event. Such a transition occurs in response to an actual 
user initiated mouse click or key depression to activate a 
hotlink appearing on a currently displayed content page in 
order to move to a new content page, either on the same site 
or on another site. Another such transition occurs whenever 
a stored history of web pages just visited by the user changes 
state. The latter is sensed by a JavaScript function that 
monitors a history stored in browser disk cache 430 of 
visited web page URLs and generates an event whenever the 
history changes state. For ease of reference, we will collec- 
tively define the term "click-stream" to encompass any 
user-initiated transition to a new content page, whether it is 
a mouse click, key depression or history state change. 

Transition Sensor events arc used to trigger the play of an 
advertisement only if, by then, all the media and player files 
for that advertisement have been fully cached into browser 
disk cache 430. Otherwise, play of that advertisement is 
deferred until after all those files are cached and the adver- 
tisement is ready to be rendered and, importantly, in 
response to the next user-initiated transition. 

Client browser 7 produces init (initialize) and start and 
stop Transition Sensor events, as symbolized by line 505 and 
510, respectively. The init and start events are produced by 
the browser to initialize (i.e., load and instantiate) and start 
the Transition Sensor applet. The stop events are also 
produced by the browser, though through a Transition Sen- 
sor stop method which has been substituted for a standard 
browser stop method, in response to detection, by the 
Transition Sensor, of user-initiated page transitions. These 
events control the state of applet 422. Transition Sensor 
applet 422 communicates directly with AdController applet 
424, as symbolized by line 535— -such as to pass an Internet 
address of an advertising server, and indirectly, as symbol- 
ized by line 530, through applet registry 426. Registry 426 
passes information, as symbolized by line 540, to AdCon- 
troller applet 424. 
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As noted above, Ad Controller applet 424 extends stan- 
dard Java applet class definitions by over-riding standard 
Java applet init, start, run, stop and destroy life cycle 
methods. Doing so, particularly in the case of the Stop 
method (which will be described below in conjunction with 5 
FIG. 18), permits the Ad Controller applet to persist in 
browser disk cache 430 as the user navigates across succes- 
sive pages and web sites. 

Advantageously, the AdController applet can readily 
function in a wide variety of environments, without changes 30 
to the coding of the applet itself. This is accomplished 
through downloading of an external configuration file 
(specifically file 620 shown in FIGS. 6A and 6B, which will 
be discussed below), as part of the applet files, from agent 
server 15. Suitably changing parameter values in the con- 35 
figuration file permits the behavior of applet 424 to be 
readily changed to suit a desired environment without a need 
to utilize a different version of that applet for each different 
environment, otherwise requiring different software classes 
and with attendant modifications and re-compilation. 20 

Execution of AdController applet 424 begins by Transi- 
tion Sensor applet 422 calling a standard init Applet method, 
which downloads the external configuration file, followed 
by extracting and saving its configuration parameters. These 
parameters are supplied, as symbolized by line 515, to the 25 
AdController applet, during its execution in order to define 
its behavior given its current execution environment. 

As noted above, AdController applet 424 "politely" and 
transparently downloads advertising (including media and, 
where necessary, player) files, through browser 7 into 30 
browser disk cache 430, for each and every advertisement 
that is to be subsequently and interstitially played. A data 
path through which advertisements are downloaded is 
shown in FIG. 5 by dot-dashed lines; while that for adver- 
tisement play is shown in this figure by dotted lines. 35 

Specifically, to download and play advertisements, applet 
424 implements Ad Pipeline 545 (which will be discussed in 
detail below in conjunction with FIG. 14). Pipeline 545 
implements various threads (processes) and data structures 
which collectively load advertising files into browser disk 40 
cache 430 (and, for media files, also into browser RAM 
cache) and then present fully downloaded advertisements. 
The pipeline implements Ad Producer, Ad Location and Ad 
Downloader processes (processes 1500, 1600, 1700 shown 
in FIGS. 15, 16 and 17, respectively, and discussed in detail 45 
below), and download queue 1430 and play queue 1470 
(both of which are shown in FIG. 14 and discussed in detail 
below). 

In essence, once Transition Sensor applet 422, as shown 
in FIG. 5, supplies AdController applet 424 with a URL of 50 
an AdDescriptor file, Ad Pipeline 545 then downloads, as 
symbolized by dot-dashed line 520, the AdDescriptor file, 
via agent server 15 (serving as a proxy server), from a 
remote advertising management system. As noted above, 
this file contains a manifest of media and player files 55 
necessary to fully play a complete advertisement. Once this 
AdDescriptor file has been downloaded into Ad Pipeline 
545, pipeline 545 then "politely" downloads, as symbolized 
by line 525, each file specified in the manifest — to the extent 
that file does not already reside on the client hard disk. 60 
Pipeline 545 then, once the downloading (to the extent 
needed) is complete, writes the AdDescriptor file to the play 
queue and each downloaded file specified therein to browser 
disk cache 430; hence forming a queued advertisement for 
subsequent access. 65 

At the inception of an interstitial interval, signaled by a 
Transition Sensor stop event, the AdController applet inter- 
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stitially plays an advertisement that has then been com- 
pletely queued — both in terms of its media and player files. 
In particular, at the start of that interval, the Ad Pipeline 
retrieves an AdDescriptor that is then situated at the head of 
a play queue. Media players 565 required by that 
advertisement, as specified in the AdDescriptor file, are 
started in the order specified in that file along with their 
corresponding media file(s). A resulting processed media 
stream, produced by the players), and as symbolized by line 
570, is rendered through browser 7 to the user. Media 
players 565 may permanently reside, i.e., apart from being 
downloaded by agent 420, on the client hard disk (thus being 
implemented by resident player files 410 as shown in FIG. 
4) or be downloaded by pipeline 545 into browser disk cache 
430 (and also browser RAM cache) for subsequent access 
and use (thus stored within files 437 shown in FIG. 4). 

Once an advertisement completely plays, AdController 
applet 424, as shown in FIG. 5, establishes an appropriate 
log entry for a "user impression" for that advertisement. 
Advertisement files are retained in the browser disk cache 
until that cache completely fills, at which point these files, 
like any other content files stored in that cache, are deleted 
by the browser on a first-in first-out (i.e., age order) basis. 
Media players 565, browser 7 and browser disk cache 430 
are all shown in dashed lines as these components, while 
being used by the AdController agent, are not viewed as 
constituting components solely within the agent itself. 

FIGS. 6A and 6B collectively depict a high-level flow- 
chart of processing operations 600 performed by AdCon- 
troller agent 420; the correct alignment of the drawing sheets 
for these figures is shown in FIG. 6. Though, the operations 
depicted in this figure — and also in FIGS. 8, 9Aand 9B, 12, 
and 14-19 — occur through a multi-threaded approach to 
process multiple advertisements on a pipelined basis, to 
simplify all these figures, the sequential processing flow 
shown in each of these figures is that which processes a 
single common advertisement. Description of threads and 
classes is provided to the extent needed to provide a suffi- 
cient understanding to those skilled in the art as to how these 
sequential processing flows would preferably be imple- 
mented through a multi-threaded Java class methodology. 

Upon entry into process 600 as shown in FIGS. 6A and 
6B, which occurs in response to an Transition Sensor init 
event from browser 7, block 610 is performed. Through this 
block, Transition Sensor applet 422 instructs the applet 
registry to load the AdController applet. Once that occurs, 
block 615 is performed through which external AdController 
configuration file 620 is retrieved from agent server 15. 
Thereafter, through decision block 630, agent 420 waits, by 
looping through NO path 631, until browser 7 generates a 
Transition Sensor start event. When such an event occurs, 
execution proceeds, via YES path 633 emanating from this 
decision block, to block 635. Through this latter block, 
AdController applet 424 obtains an Internet address of an 
advertisement management system (e.g., system 25) from 
which the agent is to retrieve AdDescriptor file 645. Applet 
424 then passes this address to Ad Pipeline 545. The Ad 
Pipeline, as indicated in block 640, then retrieves AdDe- 
scriptor file 645 from this address and particularly, and 
through agent server 15 serving as a proxy server. Once this 
file is retrieved, the agent performs block 650 which 
"politely" downloads all the media and player files 655 (to 
the extent each file does not already reside on the client hard 
disk), from advertising management system 25 (residing on 
advertising server 20), and, through block 660, stores these 
files into browser disk cache 430 (and, in the case of media 
files, into browser RAM cache). As noted above, these files 
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are downloaded via agent server 15, which here too serves 
as a proxy server. This downloading continues until either it 
finishes or a Transition Sensor stop event generated by the 
browser arises, whichever occurs first. As to the stop event, 
decision block 665 tests for its occurrence, with execution 
looping back, via NO path 666, in the absence of such an 
event. However, whenever this event occurs, such as (as 
discussed above) in response to a user-initiated page 
transition, decision block 665 routes execution, via YES 
path 668, to block 670. This latter block then, using media 
players 565, plays an advertisement then fully queued in the 
play queue on the browser disk cache, i.e., an AdDescriptor 
file for this ad then resides at a head of the play queue and 
all associated media and player files for that advertisement, 
as specified in that AdDescriptor file, then reside on the 
client hard disk. 
3. AdController Applet 424 

FIG. 7 depicts a high-level block diagram of basic execu- 
tion threads that implement AdController applet 424. 

As shown, in response to a Transition Sensor init event 
produced by the client browser, one thread executes block 
710 to initialize AdController applet 424. This block per- 
forms the downloading (to the extent necessary) and instan- 
tiation of applet 424. In response to a Transition Sensor start 
event produced by the client browser, another thread, by 
executing block 720, starts the AdController applet. Once 
this applet is started, this applet, in turn and as discussed 
above, through execution of block 730, enables download- 
ing of advertising (media and player) files to commence. In 
response to a received Internet address of a remote ad 
management system (here, e.g., system 25 shown in FIGS. 
IB and 1C) supplied by the Transition Sensor applet, a third 
thread requests, through execution block 740 shown in FIG. 
7, an AdDescriptor file from the ad management system 
situated at this address and then downloads AdDescriptor 
file 645 received in response. If, by this time, block 730 has 
enabled advertisement downloading, then advertising files, 
as specified in AdDescriptor file 645, are "politely" down- 
loaded as required. In response to a Transition Sensor stop 
event produced by the client browser and which signals an 
inception of an interstitial interval, another thread, here 
commencing with execution of block 750, suspends down- 
loading of advertisement files in favor of displaying a 
queued advertisement. Once this downloading is suspended, 
this last thread invokes block 760 to commence play of an 
advertisement then situated, in terms of its AdDescriptor file, 
at a head of the play queue. 

FIG. 8 depicts a high-level flowchart of processing opera- 
tions 800 performed by AdController applet 424. 

Upon entry into operations 800, which occurs in response 
to an init event produced by the Transition Sensor applet, 
block 805 is performed. Through this block, the AdControl- 
ler applet is initialized. This includes downloading files, to 
the extent needed, for this applet from the agent server and 
then instantiating this applet. Once this occurs, block 810 
tests for an occurrence of AdController start event produced 
by the Transition Sensor applet. Until this event occurs, 
execution merely loops back, via NO path 812, to block 810. 
When this event occurs, decision block 810 routes 
execution, via YES path 814, to block 815. This latter block, 
retrieves external AdController configuration file 620 from 
the agent server. Thereafter, block 820 occurs through which 
the AdController applet creates and starts Ad Pipeline 545. 
Once the pipeline is fully started, then, block 825 is per- 
formed to enable advertisement files to be "politely" down- 
loaded into the Ad Pipeline and to thereafter actually down- 
load such files. While advertisement files are being 
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downloaded or thereafter, if such downloading has 
completed, decision block 830 tests for an occurrence of a 
Play Ad event. If no such event occurs, then execution loops 
back, via NO path 833, to decision block 830 to continue any 

s further downloading. If however, a Play Ad event occurs, 
then decision block 830 routes execution, via YES path 837, 
to block 840. This latter block suspends further downloading 
of advertisement files into the Ad Pipeline. Once this occurs, 
then block 845, when performed, issues a request to the Ad 

10 Pipeline to play an advertisement having its AdDescriptor 
file then located at the head of the play queue. While the 
advertisement is being played, decision block 850 tests for 
an occurrence of an shutdown event generated by the 
browser, such as caused by, e.g., a user-initiated transition or 

is the user closing an advertisement window or closing the 
browser itself. If such an event does not occur, decision 
block 850 routes execution, via NO path 853, back to block 
825 to re-enable "polite" download of advertisement files 
once again. If such a shutdown event occurs, then processing 

20 operations 800 terminate, via YES path 857. 

FIGS. 9A and 9B collectively depict a flowchart of 
processing operations 900 performed by AdController 
applet 424 specifically for processing an advertisement; the 
correct alignment of the drawing sheets for these figures is 

25 shown in FIG. 9. 

Upon entry into operations 900, block 905 is performed to 
receive a request, issued by the Transition Sensor applet, to 
download a next advertisement, specifically a corresponding 
AdDescriptor file. This request contains an Internet address 

30 of a remote ad management system. In response to this 
request, AdController applet 424 performs block 910 to 
request Ad Producer process (also being a thread) 1500 to 
download an ad. The Ad Producer process, as will be 
discussed below in conjunction with FIG. 15, requests 

35 advertisement files, specifically an AdDescriptor file, from 
an Internet address communicated by the Transition Sensor 
applet. Thereafter, through block 915, the Ad Producer 
process blocks (i.e., it actively waits for its input data) untii 
this process receives the Internet address of the remote 

40 advertising management system. Thereafter, block 920 
executes to cause Ad Location process (also being a thread) 
1600 to block until such time as the AdDescriptor file is fully 
downloaded by Ad Producer process 1500 and is provided to 
the Ad Location process. Ad Location process 1600, as will 

45 be discussed below in conjunction with FIG. 16, performs 
the following tasks: (a) on startup of process 1600, this 
process creates an Ad Producer object; (b) it asks Ad 
Producer process 1500 for next AdDescriptor file 645; and 
(c) once process 1600 obtains such AdDescriptor file 645 

50 and if download queue 1430 (see FIG. 14) is not full, it 
writes that file into this queue. If this queue is then full, 
process 1600 simply waits until the queue is not full before 
writing the AdDescriptor file into the queue. Once the 
AdDescriptor file has been completely downloaded, Ad 

55 Location process 1600 inserts, as shown in block 925, this 
file into download queue 1430. 

Once AdDescriptor file 645 is inserted into the download 
queue, then Ad Downloader process (also being a thread) 
1700 executes. This process, as will be discussed below in 

60 conjunction with FIG. 17, performs a single chain of tasks. 
First, as shown by block 930, process 1700 blocks until 
such time as the AdDescriptor file for the advertisement to 
then be downloaded becomes available in the download 
queue. During its execution, this process asks download 

65 queue 1430 if there is an AdDescriptor file therein, i.e., such 
a file for which advertising files need to be downloaded. If 
the download queue is empty, then AdDescriptor process 
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1700 both waits until that queue is not empty and also For an advertisement, player mechanisms take associated 
retrieves the AdDescriptor file over the network. Once the media files specified in the associated AdDescriptor file from 
Ad Downloader process has retrieved the AdDescriptor file, the browser cache and actually display these files to a user 
this process, through executioo of block 935, requests via a viewable frame or window. The user will view a 
browser cache proxy 1450 (shown in FIG. 14) to download 5 pr c*cached smoothly playing advertisement out of the 
all ad media and player files. In response to this request, browser disk cache and, where appropriate for media files, 
browser cache proxy 1450 then downloads, as shown by from browser RAM cache, rather than being streamed in 
block 940 all the advertising files specified in the AdDe- ovef the Interaet Fouf modes fof dis laying advertisements 
scriptor file, into browser disk cache (and, m the case of are supported; namelv> user -event triggered ad play, frame- 
media files into browser RAM cache). Once aU the adver- w d ad timer . based ad play tnd PopUp Java frame 
Using files have finished downloading, the Ad Downloader . ° „ , r - £ , , r / j- i 
process, as shown in block 950, move! the AdDescriptor file P la * ^ h °f thes ^ e P|» £ er m ^ haiusms uses a media player 
to play queue 1470 (see FIG. 14). However, if the play queue ™ du e (alined within media players 565 shown in FIG 
is then full, the Ad Downloader process will wait until the 5 ) and a {h ™ d : The P laver th ™ d P rov : des an actual 
play queue is not full before moving the AdDescriptor file presentation of advertising media to the user then operating 
into this queue. 15 me c ^ ent browser The combination of a player and a player 
The Browser Cache Proxy implements an interface to an thread provides capabilities of: controlling time-based fre- 
abstract cache. The cache implementation could be any kind quency of advertisement play using an agent configurable 
of cache — the browser disk or RAM cache, a Java virtual timer; displaying advertising media files in a browser win- 
memory cache, a local raw disk cache, and so forth. Once dow or Java frame; waiting a configurable amount of time 
passed through this cache proxy, the media files that con- 20 (usually the length of the advertisement as specified in its 
stitute an advertisement will have been downloaded into AdDescriptor file); and terminating the advertisement visu- 
both disk and RAM cache of the browser. Whenever the Ad ally upon completion, or at a request of the user if the 
Downloader process subsequently tries to access any media advertisement, as configured in its AdDescriptor file, permits 
file having an identical URL to that downloaded, this pro- pre-mature termination. 

cess will first attempt to load the files from the browser disk 25 A frame-targeted play renders advertisement media onto 

cache or browser RAM cache instead of downloading the a browser window. Such play is interruptible and restartable 

file, via the Internet, from its advertising management upon user-demand. Timer-based ad play utilizes a separate 

server; thus leveraging, even across different referring web thread that continuously loops to: obtain an AdDescriptor 

pages or sites and to the extent possible, a one time down- file from the play queue; display that advertisement using a 

load of an advertising file across different advertisements. 30 player and player thread; and sleep for a specified amount of 

Next, should a Transition Sensor stop event occur, i.e., time before repeating this sequence. Timer-based ad play is 
indicative of a start of a next interstitial interval, then also interruptible and restartable upon user-demand. The 
Transition Sensor stop method 1800 will request, as shown result of this type of advertisement play is that the user will 
by execution of block 955, that AdController applet 424 then periodically view advertisements delivered at regular time 
play an advertisement. In response to this request, an event 35 intervals rather than by user initiated events. The Popup 
scheduler thread within the applet will block, as shown in Java frame play is a separate thread that also continuously 
block 960, until such time as applet 424 responds to this loops to: obtain an AdDescriptor file from the play queue; 
request by initiating play of an advertisement. The event waits for a signal that a user- initiated transition is occurring; 
scheduler thread controls playing of advertisements to the pops up a display window ("pop-up" window) in the 
user. This thread determines when to execute media players 40 browser, for a pre-defined period of time, and presents the 
specific to the next advertisement in the play queue (i.e., in advertisement in that window; and removes the pop up 
terms of corresponding AdDescriptor files situated in that window before repeating this sequence. The result of the 
queue), as well as provides a callback method which the Pop Up Java Player is that the user will view successive 
player executes when that player has successfully completed advertisements each for pre-defined time interval (which can 
presenting an advertisement as specified in its corresponding 45 vary from one advertisement to the next, as specified in the 
AdDescriptor file. Once the AdController applet has initi- AdDescriptor files for each such advertisement) whenever 
ated play of an advertisement, then, as shown by block 965, the user transitions between one web page and the next, 
the event scheduler retrieves an advertisement, specifically Once an advertisement is completely played and in the 
the corresponding AdDescriptor file, then situated at the absence, as discussed above of any instructions in the 
head of the play queue. Thereafter, the event scheduler, as 50 AdDescriptor file to replay that advertisement, such as 
shown in block 970, launches execution of the specific through, e.g., timer-based ad play, the associated AdDescrip- 
media player(s) 565 (see FIG, 5), as specified in the corre- tor file is effectively "pulled off" the play queue, 
sponding AdDescriptor file, to play this particular advertise- In particular, downloading of advertisement files occurs, 
ment. The browser disk cache provides the associated con- as discussed previously, continuously as effectively a back- 
tent files for this advertisement to the media player(s). Once 55 ground process, using a separate asynchronous thread. The 
the advertisement has been fully presented, then, as shown stop method of the Transition Sensor (specifically Transition 
in block 975, AdController applet 424, through the event Sensor stop method 1800 as will be described below in 
scheduler thread, appropriately logs this presentation into a conjunction with FIG. 18) is responsible for generating a 
log file maintained in the browser disk cache for subsequent play event to the AdController agent. This event notifies the 
uploading to the agent server. Execution then exits from 60 agent of an opportunity to present a downloaded advertise- 
operations 900. ment to the user. This stop method is called automatically by 

A logger process (also implemented as a thread) keeps the client browser whenever a user transitions off a web page 

track of all log entries that need to be sent back to the agent that contains the embedded advertising tag. In particular, this 

server. This process simply timestamps entries and adds method invokes a start player method in the AdController 

them to a log buffer. Then, periodically, the logger process 65 agent. The start player method, in turn, invokes a similarly 

will flush the log back to the agent server where those entries named method, in the event scheduler, which initiates and 

can be archived and analyzed. controls the presentation of advertisements during content 
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page transitions. The event scheduler ensures all media files 
for an advertisement have been transparently downloaded 
before their presentation, as well as exercises control over 
actual execution of the appropriate player classes required to 
visibly render the advertisement. In that regard, the event 
scheduler instantiates and invokes a player class appropriate 
for the current advertisement by calling a start method of 
that class. This start method creates the player thread that 
performs visual rendering of the advertisement. Then, this 
start method calls a run method of the player thread in order 
to visually present the advertising media from the browser 
disk and RAM caches. Upon completion, based on the 
configuration of the advertisement, the run method, by 
executing its own stop method, terminates the advertisement 
either upon detecting a close request by the user or comple- 
tion of ad play timeout. The stop method performs any 
player software termination and cleanup, finally executing a 
callback to the scheduler object. 

4. Inter-applet Events Involving Transition Sensor Applet 
422 

FIG. 10 depicts inter-applet events 1000 that occur within 
AdController agent 420 during execution of Transition Sen- 
sor applet 422. 

As shown and discussed above, whenever a browser 
interprets and then executes advertising tag 40, specifically 
tag 42 therein, situated within content page 35, this causes, 
as symbolized by line 1010, the browser to download script 
200 (see FIGS. 2A and 2B) from the agent server. This 
applet, in turn, dynamically writes Transition Sensor applet 
210 (also referred to as applet 422) into the referring web 
content page. As discussed above, once this applet is instan- 
tiated and executed by the client browser, the applet, in turn, 
instantiates applet registry 426. 

Once the applet registry is instantiated, the Transition 
Sensor queries the registry, this operation being symbolized 
by line 1015, to determine current status of the AdController 
applet. If, as symbolized by line 1020, the registry indicates 
that the AdController applet is not loaded and hence is not 
executing, then Transition Sensor applet 422 loads, as sym- 
bolized by line 1025, AdController applet 424 from the 
browser disk cache, and then instantiates and starts this 
applet. Once the AdController applet is instantiated, the 
Transition Sensor applet writes, as symbolized by line 1030, 
appropriate entries, indicating that both the Transition Sen- 
sor applet is loaded and, as symbolized by line 1035, that the 
AdController applet is loaded, into is the applet registry. 
Once this occurs, then the applet registry returns, as sym- 
bolized by line 1040, an appropriate handle for the AdCon- 
troller applet to the Transition Sensor in order to permit the 
latter to refer to the former. Thereafter, as symbolized by line 
1060, the Transition Sensor passes, as discussed above, a 
request containing an Internet address of an advertisement 
management system to the AdController applet to download 
an AdDescriptor file, for an advertisement, from that 
address. This address is specified in tag 44 of advertising tag 
40 and, as symbolized by dashed line 1050, incorporated 
into the request. Thereafter, the Transition Sensor, in 
response to a user-initiated transition (click-stream) to a next 
content web page, executes its stop method (method 1800 
shown in FIG. 18) to instruct, i.e., issue a request to, as 
symbolized by line 1065, the AdController applet to play a 
fully downloaded advertisement having its corresponding 
AdDescriptor file then situated at the head of the play queue. 
Once this occurs, the Transition Sensor applet terminates its 
execution until the browser next encounters, interprets and 
executes a content page containing advertising tag 40 at 
which point the Transition Sensor applet is re-loaded and 
re-started; and so forth. 
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5. Transition Sensor Applet 422 

FIG. 11 depicts a high-level block diagram of basic 
processing threads that implement Transition Sensor applet 
422. 

As shown, in response to a Init (Initialize) Transition 
Sensor applet event produced by the client browser, a thread 
commences by executing block 1110 to initialize Transition 
Sensor applet 422. This thread, in turn, executes block 1120 
to load AdController applet 424 from browser disk cache or 
download it from the agent server, if necessary, and then 
load it. Thereafter, this thread executes block 1130 to obtain 
the Internet address of an advertising management system 
(e.g., system 25 shown in FIGS. IB and 1C, 2A and 2B, and 
10) in tag 44 from advertising tag 40. 

As shown in FIG. 11, in response to a Start Transition 
Sensor applet event generated by the client browser, another 
thread commences by executing block 1140 to enable Ad 
Downloader process 1700 (as discussed above, and to be 
discussed in detail below in conjunction with FIG. 17) to 
commence "polite" downloading an AdDescriptor file and 
all required and associated advertisement files (both media 
and player) into the browser disk cache. 

Further, as shown in FIG. 11, in response to a Stop 
Transition Sensor applet event generated by the client 
browser, a third thread commences by executing block 1150 
to disable Ad Downloader process 1700 and thus suspend 
further downloading of advertisement files. Once this 
occurs, this thread then executes block 1160 to instruct the 
AdController applet to play a fully downloaded advertise- 
ment having its corresponding AdDescriptor file then situ- 
ated at the head of the play queue. 

FIG. 12 depicts a high-level flowchart of processing 
operations 1200 performed by Transition Sensor applet 422. 

Upon entry in operations 1200, decision block 1210 tests 
for an occurrence of an init event produced by the client 
browser. Until such an event occurs, execution loops back, 
via NO path 1213, to block 1210. When this event occurs, 
execution proceeds, via YES path 1217 to block 1220 which, 
when performed, initializes Transition Sensor applet 422. 
r rhereafter, block 1230 is performed through which the 
Transition Sensor applet 424 instructs, by issuing a request 
to, the AdController applet to download an advertisement, 
specifically as discussed above an AdDescriptor file from an 
ad management server specified in the advertising tag. Once 
this occurs, decision block 1240 tests for an occurrence of a 
Transition Sensor start event generated by the client 
browser. Until such an event occurs, execution loops back, 
via NO path 1243, to block 1240. When this particular event 
occurs, execution proceeds, via YES path 1247 to block 
1250 which, when performed, enables Ad Pipeline 545 to 
download the AdDescriptor file and associated advertising 
files. 

Next, decision block 1260 tests for an occurrence of a 
Transition Sensor stop event generated by the client browser. 
Until such an event occurs, execution loops back, via NO 
path 1263, to block 1260. When a Transition Sensor stop 
event occurs, execution then proceeds, via YES path 1267 to 
block 1270 which, when performed, requests that AdCon- 
troller applet 424, specifically via Ad Pipeline 545, then play 
an advertisement. 

6. Ad Loader Process 1300 

FIG. 13 depicts a high-level block diagram of Ad Loader 
process 1300 which forms a portion of AdController applet 
424. Process 1300 provides an advertiser (specifically an 
advertising programmer) with control over various 
functions, for advertisement play and logging, implemented 
by the AdController applet, specifically how and where this 
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applet retrieves advertisements across a networked connec- waits until it receives the Internet address of the remote 

tion and how those advertisements are played. Through use advertising management system, whereupon this process 

of the Ad Loader, the AdController applet can be controlled, then downloads AdDescriptor file 645 from the specified ad 

to an extent desired, by external programmatic calls. management system. Once this file has been downloaded, 

As shown, this process includes Ad Loader API 5 block 1420, shown in FIG. 14, executes to invoke Ad 

(application programming interface) 1310 which interfaces Location process 1600 (which will be discussed in detail 

to Ad Pipeline 545 and through this pipeline controls how below in conjunction with FIG. 16). During its execution, 

advertisements are presented, as symbolized by block 1370, Ad Location process 1600 blocks until such time as AdDe- 

by the player mechanisms. In particular, the Ad Loader API scriptor file 645 is fully downloaded by Ad Producer process 

provides information regarding and, through setting various 10 1500 and is provided to the Ad Location process, whereupon 

program variables, permits programmer control over adver- the Ad Location process writes this AdDescriptor file into 

tisement display and downloading operations. In that regard, download queue 1430. 

these variables provide a callback to the AdController applet After AdDescriptor file 645 has been written into the 

indicating when a content page to which the user has just download queue, Ad Location process 1600, as will be 

transitioned has completed its downloading; and can be used 15 discussed below in conjunction with FIG. 16, performs the 

to: instruct the AdController applet when to download a next following tasks: (a) on startup of process 1600, this process 

advertisement, when to play a next advertisement fully creates an Ad Producer object; (b) this process asks Ad 

queued in the Ad Pipeline, start and stop a play timer (for use Producer process 1500 for next AdDescriptor file 645; and 

with, e.g., timer-based ad play, as discussed above), log a (c) once process 1600 obtains AdDescriptor file 645 and, if 

message, set a mode so as to specify a desired location to 20 download queue 1430 is not full, process 1600 writes that 

display advertisements, suspend and resume download of file into this queue. If this queue is then full, process 1600 

advertisement files into the Ad Pipeline, suspend a current simply waits until the queue is not full before writing the 

download for a given period of time, and suspend and AdDescriptor file into the queue. Once the AdDescriptor file 

resume advertisement play by the player mechanisms. has been completely downloaded, Ad Location process 1600 

In that regard, the Ad Loader API configures Ad Pipeline 25 inserts, as shown in block 925, this file into download queue 

545 such that AdDescriptor file 645 is downloaded, as 1430, 

symbolized by block 1320, from a remote ad management Once AdDescriptor file 645 is inserted into the download 
system into the Ad Pipeline in response to receipt of an queue, then block 1440 executes to invoke Ad Downloader 
Internet address of an ad management system and, for process 1700. Process 1700, which will be discussed below 
targeted advertisements, a URL of a referring web page 30 in conjunction with FIG. 17, performs a single chain of 
address. As symbolized by block 1330, the API configures tasks. First, process 1700 blocks until such time as the 
the Ad Pipeline such that advertisement downloading is downloaded AdDescriptor file has become available in the 
enabled only when AdController applet 424 is not playing an download queue. During its execution, this process asks 
advertisement. Furthermore, as symbolized by block 1340, download queue 1430 if it contains an AdDescriptor file, 
the API configures the Ad Pipeline such that advertisement 35 e.g., file 645. If so, then advertising files need to be down- 
downloading is disabled whenever the AdController applet loaded for that particular AdDescriptor file. If the download 
is playing an advertisement. Furthermore, as symbolized by queue is empty, then process 1700 both waits until that 
block 1350, the API configures the Ad Pipeline such that queue is not empty and also retrieves the AdDescriptor file 
advertisement play is to commence in response to a request over the network. Once Ad Downloader process 1700 has 
to play a next advertisement, i.e., one that is fully cached in 40 obtained this AdDescriptor file, process 1700 then 
the browser disk cache and having its AdDescriptor file then downloads, all the media and required player files specified 
situated at the head of the play queue. in the AdDescriptor file by using Browser Cache Proxy 
7. Ad Pipeline 545 1450, into browser disk (and RAM) cache 1460. Once all the 

FIG. 14 depicts a high-level block diagram of Ad Pipeline advertising files have finished downloading, process 1700 

545. As discussed above, the Ad Pipeline implements vari- 45 moves the AdDescriptor file to play queue 1470. However, 

ous threads and data structures which collectively load if the play queue is then full, the Ad Downloader process 

advertising files (needed media and player files) into the waits until play queue 1470 is not full before moving the 

browser disk cache and, for media files, also into browser AdDescriptor file into this queue for subsequent ad play. As 

RAM cache, and then present fully downloaded advertise- discussed above, AdDescriptor file 645 for a fully queued ad 

ments. As noted, the Ad Pipeline employs Ad Producer 50 (i.e., with its all the associated media and player residing on 

process 1500, Ad Location process 1600 and Ad Down- the client hard disk) is subsequently retrieved from play 

loader process 1700 (all of these processes, as noted above, queue 1470 in response to a request to play an 

are also threads). advertisement, this request being issued in response to a 

In response to an incoming request to download an Transition Sensor stop event, 

advertisement, Ad Pipeline 545 is invoked. Specifically, 55 8. Ad Producer Process 1500 

within this pipeline, first block 1410 executes to invoke Ad FIG. 15 depicts a high-level block diagram of Ad Pro- 
Producer process 1500 in response to an incoming request to ducer process 1500. As noted above, this process requests an 
download an advertisement. As discussed above, this AdDescriptor file from an Internet address communicated by 
request, issued by the Transition Sensor applet, includes an the Transition Sensor applet and subsequently downloads 
Internet address of a remote ad management system (e.g., 60 that file into the browser disk cache, 
system 25 shown in FIGS. IB and 1C) on which an As shown, upon entry into process 1500, execution first 
advertisement resides and is to be downloaded (through proceeds to decision block 1510. This block determines 
agent server 15 as a proxy server). Ad Producer process whether a URL has been received, from the Transition 
1500, as will be discussed below in conjunction with FIG. Sensor, from which to fetch an AdDescriptor file. If such a 
15, requests advertisement files, specifically an AdDescrip- 65 URL has not yet been received, then execution loops back, 
tor file (e.g., file 645), from an Internet address specified in via NO path 1517, to this decision block. Alternatively, if 
the request. During its execution, the Ad Producer process such a URL has been received, then execution proceeds, via 
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YES path 1513, to block 1520 which, in turn, stores this 
URL, as Ad URL 1530, for use during a next successive 
advertisement download opportunity. 

Once this URL has been so stored, execution proceeds to 
decision block 1540. This block tests for an occurrence of a 5 
user-initiated event (click-stream) signifying that advertise- 
ment downloading can now occur, such as, e.g., when the 
user has just closed an existing advertisement frame and a 
next successive content page to which the user has transi- 
tioned is being rendered by the client browser. If such an 1Q 
event has not yet occurred, e.g., the next successive content 
web page is downloading, then execution merely loops back, 
via NO path 1543, back to decision block 1540. However, if 
such an event occurs, then this decision block routes 
execution, via YES path 1547, to block 1550. This latter 
block, when executed, downloads AdDescriptor file 645 15 
using the URL communicated by the Transition Sensor. 
Once this file is completely downloaded, then block 1560 
executes to transfer this file to Ad Location process 1600. 
Thereafter, execution loops back, via path 1565, to decision 
block 1510, and so forth. 20 

9. Ad Location Process 1600 

FIG. 16 depicts a high-level block diagram of Ad Loca- 
tion process 1600. This process, as discussed above, accom- 
plishes the following tasks: (a) on startup of this process, 
process 1600 creates an Ad Producer object; (b) process 25 
1600 asks Ad Producer process 1500 for next AdDescriptor 
file 645; and (c) once process 1600 obtains AdDescriptor file 
645 and, if download queue 1430 (see FIG. 14) is not full, 
process 1600 then writes that file into this queue. If this 
queue is then full, process 1600 simply waits until the queue 30 
is not full before writing the AdDescriptor file into the 
queue. 

Upon entry into process 1600 and with respect to adver- 
tisement downloading itself, execution proceeds to decision 
block 1610. This decision block, when executed, determines 35 
whether an Internet address (URL) of an ad management 
system has been received from the Transition Sensor applet 
for a next successive advertisement download. If that 
address has not yet been received, then execution merely 
loops back, via NO path 1613, to decision block 1610. 40 
Alternatively, if such an address has been received but not 
yet processed, then decision block 1610 routes execution, 
via YES path 1617, to block 1620. This latter block requests 
Ad Producer process 1500 to download an AdDescriptor 
file, e.g., file 645, from this URL. Once this request occurs, 45 
execution proceeds to decision block 1630 to determine 
whether this AdDescriptor file has been completely down- 
loaded. If this file download is still occurring, then execution 
merely loops back, via NO path 1633, to block 1630 to await 
completion of the download. Once this download completes, 50 
decision block 1630 routes execution, via YES path 1637, to 
block 1640. Ill is latter block writes the downloaded AdDe- 
scriptor file into download queue 1430 (providing this queue 
is not full). Once this occurs, execution is directed, via path 
1645, back to decision block 1610, and so forth. 55 

10. Ad Downloader Process 1700 

FIG. 17 depicts a high-level block diagram of Ad Down- 
loader process 1700. Essentially, as discussed above, pro- 
cess 1700 determines, from the download queue, if that 
queue contains an AdDescriptor file, e.g., file 645. If it does 60 
contain such an AdDescriptor file, then advertising files need 
to be downloaded for that file. Consequently, process 1700 
then downloads required advertising files specified in that 
AdDescriptor file. Once this fully occurs, process 1700 
moves the AdDescriptor file to the play queue. 65 

In particular upon entry into process 1700, execution 
proceeds to decision block 1710. This decision block deter- 
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mines whether the download queue then contains an AdDe- 
scriptor file, e.g., file 645. If the queue is empty, then 
execution merely loops back, via NO path 1717, to this 
decision block to await such an AdDescriptor file. However, 
if download queue 1430 then contains such a file, process 
1720 obtains the AdDescriptor file then situated at the head 
of this queue. Thereafter, block 1730 executes. This block 
downloads all the required advertising files, not then resi- 
dent on the client hard disk, into browser proxy cache 1450. 
This block also transfers all the associated media files in the 
browser proxy cache to the browser RAM cache. Execution 
then proceeds to decision block 1740 which determines 
whether all required advertising files have then been down- 
loaded. If any such file remains to be downloaded, then 
decision block 1740 routes execution, via NO path 1747, 
back to block 1730 to download that file. Alternatively, if all 
the required advertising files have been downloaded, then 
execution proceeds, via YES path 1743, to block 1750. This 
latter block moves the AdDescriptor file from download 
queue 1430 to an end of play queue 1470. Once the 
AdDescriptor file is written into the play queue, the corre- 
sponding advertisement is then ready to be presented to the 
user, in order relative to other AdDescriptor files then 
queued in the play queue, during an ensuing interstitial 
interval. 

11. Transition Sensor Stop Method 1800 

FIG. 18 depicts a flowchart of stop method 1800 invoked 
by Transition Sensor applet 422. This method, in response to 
a stop event generated by the browser, suspends download- 
ing of advertisement files and initiates interstitial ad play. 

In particular, upon entry into method 1800, decision block 
1810 executes to determine if a stop event has been received 
from browser 7. If such a stop event has yet not occurred, 
then execution loops back, via NO path 1813, back to block 
1810 to await occurrence of this event. When this event 
occurs, decision block 1810 directs execution, via YES path 
1817, to decision block 1820. This latter decision block 
determines if AdController applet 424 is then loaded and 
executing. If this applet is not then executing, decision block 
1820 routes execution, via NO path 1827, to block 1830. 
This latter block inhibits any request from being made to the 
AdController applet to play any advertisement until that 
applet is executing and, once that occurs, a next user- 
initiated (click-stream) event occurs. Thereafter, execution 
of method 1800 terminates. Alternatively, if the AdControl- 
ler applet is loaded and executing, then decision block 1820 
routes execution, via YES path 1823, to block 1840. This 
latter block requests the AdController applet to play a next 
advertisement. Once this request is issued, then execution 
proceeds to block 1850. This block, in turn, requests the 
AdController applet to suspend "polite" background down- 
loading of advertisement files while a next successive web 
content page, as requested by the user, is being downloaded 
by the browser. Once block 1850 executes, execution of 
method 1800 terminates. 

12. Transition Sensor Start Method 1900 

FIG. 19 depicts a flowchart of start method 1900 invoked 
by Transition Sensor applet 422. This method, in response to 
a start event generated by the browser, resumes background 
downloading of advertisement files. 

Specifically, upon entry into method 1900, execution 
proceeds to decision block 1910 which, when executed, 
determines if a start event has been received from browser 
7. If such a start event has not yet occurred, then execution 
loops back, via NO path 1913, back to block 1910 to await 
occurrence of this event. When this event occurs, decision 
block 1910 directs execution, via YES path 1917, to decision 
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block 1920. This latter decision block determines if AdCon- 
troller applet 424 is then loaded and executing. If this applet 
is not then executing, decision block 1920 routes execution, 
via NO path 1927, to block 1930. Block 1930 inhibits any 
request from being made to the AdControllcr applet to 5 
download any advertisement until that applet is executing 
and, once that occurs, a next user-initiated (click-stream) 
event occurs. Once the Ad Controller applet begins executing 
and thereafter a next user-initiated (click-stream) event 
occurs, execution proceeds to block 1940. This latter block 10 
requests the AdController applet to resume background 
downloading of advertisement files. Once this downloading 
is resumed, method 1900, through execution of block 1960, 
waits for browser 7 to call Transition Sensor stop method 
1800 whenever the user next unloads a web page currently 15 
rendered by the browser, i.e., causes a user initiated -event to 
transition to a next successive web page. Alternatively, if the 
AdController applet is loaded and executing, then decision 
block 1920 routes execution, via YES path 1923, to block 
1950. Since at this point the next successive content web 20 
page has been fully executed by the browser and is, e.g., 
rendered to the user, block 1950 issues a request, through the 
applet registry, to the AdController applet to enable it to 
resume background downloading of advertisement files. 
Once this occurs, block 1940 is executed to issue a request 25 
to the AdController applet to resume the background down- 
loading. Execution then proceeds to block 1960 to wait for 
browser 7 to call Transition Sensor stop method 1800 
whenever the user next unloads a web page currently 
rendered by the browser, i.e., causes a user initiated -event to 30 
transition to a next successive web page. Whenever the 
browser generates a next Transition Sensor stop event, 
process 1900 terminates. 

Although a single embodiment which incorporates the 
teachings of our present invention has been shown and 35 
described in considerable detail herein, those skilled in the 
art can readily devise many other embodiments and appli- 
cations of the present invention that still utilize these teach- 
ings. 

We claim: 40 

1. Apparatus for use in rendering an information object, 
comprising a web advertisement, through an executing web 
browser and in response to a first web page provided to the 
browser, the apparatus comprising: 

a processor; 45 

a memory connected to the processor and storing both 
computer executable instructions and the first web 
page, the first web page having a plurality of computer 
readable instructions representing page content and 
code, the code comprising an advertising tag; and 50 

an output device responsive to the processor; 

wherein the processor, in response to the executable 
instructions and the code: 

dynamically writes a plurality of predefined applet tags, 55 
that collectively implement a script, into the first web 
page; 

downloads in response to subsequent execution of the 
script, an agent from a corresponding network server 
into the memory; and 60 

thereafter instantiates and executes the agent under web 
browser, the agent having an applet, wherein the applet: 

issues a request, via a network connection, to a specified 
network server to download a manifest file for the 
information object from the specified network server, 65 
wherein the manifest file comprises a manifest of 
names of a plurality of predefined informational files 
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that collectively comprise part of the information 
object, a network address at which each of the infor- 
mational files can be accessed and associated configu- 
ration information necessary to properly render the 
information object; 
accesses and downloads, to the memory, each informa- 
tional file, specified in the manifest file, from its 
corresponding network address, to the extent said each 
informational file does not then reside within the 
memory; and 

in response to an occurrence of a user-initiated event, as 
detected by the agent through monitoring a user click- 
stream, which initiates a transition from the first web 
page to a second web page and which signifies a start 
of an interstitial interval: 

ceases any further download of the manifest file or any 
informational file specified in the manifest file, to the 
extent any downloading of said manifest file or said any 
informational file is then occurring; and 

initiates processing, through the browser, of informational 
files for a previously downloaded information object so 
as to render the previously downloaded object during 
an interstitial interval to the user. 

2. The apparatus in claim 1 wherein the applet comprises 
a download queue and a play queue, wherein, the processor 
during execution of the applet: 

inserts an associated manifest file for a advertisement to 
be downloaded into an end of the download queue; 

downloads advertising files specified in a given manifest 
file, then situated at a head of the download queue, into 
browser storage; 

once all the advertising files specified in the given mani- 
fest file for a corresponding advertisement reside in the 
browser storage on the computer, removes the given 
manifest file from the download queue and inserts the 
given manifest file into an end of the play queue; and 

in response to the user- initiated event and during the 
ensuing interstitial interval, processes advertising files 
specified in a specific manifest file then situated at a 
head of the play queue so as to render, through the 
output device, an advertisement, corresponding to the 
specific manifest file, to the user. 

3. The apparatus in claim 2 wherein the manifest file 
comprises an Ad Descriptor file. 

4. The apparatus in claim 2 wherein the advertising code 
further comprises a component designating the specified 
network server. 

5. The apparatus in claim 4 wherein the processor, during 
execution of the applet and in response to the component 
contained in the code, downloads the manifest file originat- 
ing from the specified network server designated in the 
component, the specified network server being an advertis- 
ing server. 

6. The apparatus in claim 2 wherein the agent produces a 
stop event in response to the user-initiated event and the 
applet processes the stop event to suspend said downloading 
of further advertisement files and to render the advertise- 
ment associated with the manifest file then situated at the 
head of the play queue. 

7. The apparatus in claim 2 wherein the applet comprises 
an Ad Controller applet. 

8. The apparatus in claim 2 wherein the applet processes 
each advertisement as a separate thread so as to effectuate 
pipe- lined processing of different successive advertise- 
ments. 

9. In apparatus for use in rendering an information object, 
comprising a web advertisement, through an executing web 
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browser and in response to a first web page provided to the 
browser, the apparatus having a processor, a memory con- 
nected to the processor and storing both computer execut- 
able instructions and the first web page, the first web page 
having a plurality of computer readable instructions repre- 5 
senting page content and code, the code containing an 
advertising tag, and an output device responsive to the 
processor, a method comprising the steps, performed by the 
processor in response to the executable instructions and the 
code, of: 30 
dynamically writing a plurality of predefined applet tags, 

that collectively implement a script, into the first web 

page; 

downloading in response to subsequent execution of the 
script, the agent from a corresponding network server 15 
into the memory; and 

thereafter instantiating and executing the agent under the 
browser, an agent having an applet, wherein the applet 
performs the steps of: 2Q 

issuing a request, via a network connection, to a specified 
network server to download a manifest file for the 
information object from the specified network server, 
wherein the manifest file comprises a manifest of 
names of a plurality of predefined informational files 2 s 
that collectively comprise part of the information 
object, a network address at which each of the infor- 
mational files can be accessed and associated configu- 
ration information necessary to properly render the 
information object; 30 

accessing and downloading, to the memory, each infor- 
mational file, specified in the manifest file, from its 
corresponding network address, to the extent said each 
informational file does not then reside within the 
memory; and 35 

in response to an occurrence of a user-initiated event, as 
detected by the agent through monitoring a user click- 
stream, which initiates a transition from the first web 
page to a second web page and which signifies a start 
of an interstitial interval: 40 

ceasing any further download of the manifest file or any 
informational file specified in the manifest file, to the 
extent any downloading of said manifest file or said any 
informational file is then occurring; and 

initiating processing, through the browser, of informa- 
tional files for a previously downloaded information 
object so as to render the previously downloaded object 
during the interstitial interval to the user. 



,451 Bl 

42 

10. The method in claim 9, wherein the applet comprises 
a download queue and a play queue, further comprising the 
steps, performed by the processor during execution of the 
applet, of: 

inserting an associated manifest file for a advertisement to 
be downloaded into an end of the download queue; 

downloading advertising files specified in a given mani- 
fest file, then situated at a head of the download queue, 
into browser storage; 

once all the advertising files specified in the given mani- 
fest file for a corresponding advertisement reside in the 
browser storage on the computer, removing the given 
manifest file from the download queue and inserting the 
given manifest file into an end of the play queue; and 

in response to the user-initiated event and during the 
ensuing interstitial interval, processing advertising files 
specified in a specific manifest file then situated at a 
head of the play queue so as to render, through the 
output device, an advertisement, corresponding to the 
specific manifest file, to the user. 

11. The method in claim 10 wherein the manifest file 
comprises an Ad Descriptor file. 

12. The method in claim 10 wherein the advertising code 
further comprises a component designating the specified 
network server. 

13. The method in claim 12 further comprising the step, 
performed by the processor during execution of the applet 
and in response to the component contained in the code, of 
downloading the manifest file originating from the specified 
network server designated in the component, the specified 
network server being an advertising server. 

14. The method in claim 10 further comprising the steps, 
performed by the agent, of: 

producing a stop event in response to the user-initiated 
event; and 

processing the stop event to suspend said downloading of 
further advertisement files and to render the advertise- 
ment associated with the manifest file then situated at 
the head of the play queue. 

15. The method in claim 10 wherein the applet comprises 
an Ad Controller applet. 

16. The method in claim 10 further comprising the step, 
performed by the applet, of processing each advertisement 
as a separate thread so as to effectuate pipe -lined processing 
of advertisements. 

***** 
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